[Top][All Lists]

[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: Tue, 6 Nov 2012 21:35:05 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Nov 06, 2012 at 08:55:12PM +0100, Nicolas Goaziou wrote:
> Toby Cubitt <address@hidden> writes:
> > I doubt it can be done now, since we already allow user-defined format
> > strings.
> I'm more focused on what we will be able to do.
> > 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.
> In org-element.el.

But that only needs to parse clock strings stored in properties/drawers,
not the ones displayed in overlays (column view) or in the mode-line.

Are the clock strings stored in properties/drawers formatted using the
existing org-time-clocksum-* defcustoms? I can't easily tell from the
org-clock.el code...

The only sane answer ought to be "no" (which doesn't mean that it is ;)
It would clearly be better if the clock strings stored in org buffers
used a single fixed format, which could be mangled as desired for display
in overlays and the mode-line.

> > 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"?)
> We can allow a limited set of conses of format strings (with or without
> days), possibly defined in the same defcustom (see
> `org-table-number-regexp' customize interface). If we know the format
> string used, we can parse it back.

Ugh. Wouldn't it be far better to make sure the customization options
only affect the visual display of clocksum durations (in
overlays/mode-line), and not the strings stored in the file? Then the
parser can be kept simple and reliable.

> > That would give me the format I want, but it's a feature regression.
> There are features more honoured in the breach than in the observance.
> I want to have a parseable Org syntax, for its own good.

Best way to achieve this is to separate style from content!

That would allow the visual clocksum format can be customized to our
hearts content, whilst keeping the parser simple and therefore reliable.

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]