emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [PATCH] Separate clocksum format for durations >= 1 day


From: Toby Cubitt
Subject: Re: [O] [PATCH] Separate clocksum format for durations >= 1 day
Date: Mon, 5 Nov 2012 19:16:53 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Nov 05, 2012 at 06:40:20PM +0100, Achim Gratz wrote:
> Nicolas Goaziou writes:
> > Then let's wait for Achim (Cc'ed) to illustrate what he has in mind,
> > because his proposal is too vague yet to permit discussion about it.
> 
> What I had in mind was to remove org-time-clocksum-format and replace
> the associated format calls with a formatting function that has
> customizable behaviour (how customizable is t.b.d.).
> 
> (format org-time-clocksum-format h m) => (org--format-time n fmt)
>
> Even if nothing else changes, that removes a lot of unnecessary code
> duplication, like the seven or so different ways to split the hours
> from the minutes that may or may not agree on their results.

I think whatever we end up doing, it's going simply things and remove
duplicate code. Which I agree is definitely a good thing.

> This is not far from your own suggestion to provide different functions
> depending on which output is desired, I just happen to think that these
> functions would all be so similar that they should be rolled into a
> single function that can produce different outputs.  I think there'd
> only be a handful of possible values for fmt based on the current usage
> and that suggests just another cond form would be needed in
> implementing this function rather than a full-blown format string
> interpreter.

It seems to me your `org--format-time' function would end up looking very
like what I sketched. A cond to switch between "hh:mm", "hh.mm",
"dd hh:mm" or "dd hh.mm" based only on the contents of the fmt argument
would have to check whether fmt contains 2 or 3 %-sequences, then check
if it contains "." or ":"

If these 4 options are the only ones that are ever going to be useful, we
could instead just have a single defcustom with a 4-way choice (between 4
different descriptive symbols). This would remove some flexibility from
the existing version (as well as adding some), but it's simpler than
partially parsing the fmt string.

Toby
-- 
Dr T. S. Cubitt
Mathematics and Quantum Information group
Department of Mathematics
Complutense University
Madrid, Spain

email: address@hidden
web:   www.dr-qubit.org



reply via email to

[Prev in Thread] Current Thread [Next in Thread]