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

[Toby Cubitt <tsc25@cantab.net>]

On Tue, Nov 06, 2012 at 06:41:06PM +0100, Nicolas Goaziou wrote:
> Toby Cubitt <tsc25@cantab.net> writes:
> 
> > 4. We replace the existing muddle with two defcustoms, one selecting
> >    regular or decimal (or user-defined function), and one specifying a
> >    list of standard format strings that the function can choose between,
> >    depending on the duration.
> >
> > No custom format required, no format string parsing required.
> 
> I'm talking about the other parsing: from the displayed duration to
> a number of minutes. It cannot be done if we allow user-defined
> functions.

I doubt it can be done now, since we already allow user-defined format
strings.

Where are displayed durations formatted with org-time-clocksum-format et
al. parsed back to a number of minutes in the current code? If there is
anywhere, it's surely broken because a user-supplied
`org-time-clocksum-format' or `org-time-clocksum-fractional-format' could
already format the duration in arbitrarily bizarre ways as things are
currently.

> Also, I'd rather have one defcustom than two for a simple thing like
> duration display.

There are currently three, four with my original patch. Reducing this to
two whilst simultaneously increasing customizability and ensuring a
uniform format doesn't seem so bad :)

We're trying to allow two fundamentally different things here:

1. Change the values that are computed and displayed (e.g. condition
   on < 1 day vs. >= 1 day; use fractional minutes or not).

2. Customize the way those values are formatted ("3:15" vs. "3h 15min").

It seems fairly natural to separate these into two defcustoms, rather
than try to somehow mash two rather different types of customization into
one. The same logic was presumably lurking behind the separation of
org-time-clocksum-use-fractional and
org-time-clocksum-[fractional-]format.

If we want to allow the kind of flexibility you were proposing, then
pre-canned options (or user-defined function) are a good fit to 1. and
format strings are the natural choice for 2.

If all we want to do is allow the existing regular or fractional formats
to be conditioned on the duration, a 100% backwards-compatible
alternative could be to allow org-time-clocksum-[fractional-]format to be
either a single format string (as currently) or a list of format
strings. In the latter case, the first element would be used for
durations < 1 day, the second for durations >= 1 day (extending to
months/years/decades in the obvious way if desired).

The benefits of this over my original patch are: (a) it avoids
introducing any new defcustoms or changing the existing ones in a
backwards-incompatibility way; (b) it could easily be generalised if
desired (now or in future) to condition the format on further duration
ranges. The disadvantages are: (i) it doesn't have the flexibility of
user-defined format functions; (ii) it doesn't simplify the existing
defcustoms.

> So, I still suggest to provide an unique, although conditional, display
> for duration. If you still want to allow customization, make sure it can
> be parsed back (or better, provide the parser). I'm not fundamentally
> against format strings.

You mean abandon any sort of customizable format string (since that
inherently can't be parsed back in general), and use a hard-coded
conditional "hh:mm" or "dd hh:mm" format? (Possibly retaining one
customisation option, org-time-clocksum-use-fractional, to switch this to
"hh.mm" or "dd hh.mm"?)

That would give me the format I want, but it's a feature regression.

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

email: tsc25@cantab.net
web:   www.dr-qubit.org