emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [O] [ANN] New Org duration library


From: Achim Gratz
Subject: Re: [O] [ANN] New Org duration library
Date: Tue, 21 Feb 2017 20:47:00 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.91 (gnu/linux)

Nicolas Goaziou writes:
> You can post your old customization here, I try to help you convert it
> to the new format, if possible at all.

Well, once I remembered why I had to customize it, things fell into
place.  It wasn't something complicated, just that I wanted all
durations shown in h:mm, without days (for the timetable at work).

>> I'd first need to understand what the options there really mean.  It
>> seems that the variable can be set to just a symbol or (maybe) a string
>> or a list of conses.
>
> Strings are not allowed. It is either a symbol (h:mm:ss or h:mm) or
> a list of conses.

That sentence in the documentation would have helped.

>> I don't really see why you'd mix symbols and strings in the same
>> position.
>
> Probably because I couldn't find a better idea to cover all cases.

If units are defined as strings, then why can the format not be a string
also?  I still find this confusing, especially as there are multiple
other places in Org that use format strings quite happily.

>> I have no idea what "mixed mode" is supposed to be
>
> The definition of "mixed mode" is in the docstring:
>
>   When any of the first two is present, a duration is expressed in
>   mixed mode, where the hours and minutes of the duration are
>   expressed as a \"H:MM:SS\" or \"H:MM\" string while still using
>   other units defined.

Lost me right there again.  Please tell the user what problem he can
solve with this and then tell him how to do it, not the other way
around.  So, the purpose of this variable is to specify how you want
durations displayed in Org, using the predefined "special" formats or
user-defined org-duration units (there's a default on those as well).  A
duration format doesn't necessarily use all defined units, and of those
it is using it (always?) starts with the largest unit and ends with the
smallest.  This is the only one that can usefully have PRECISION, I
suppose, but the docstring shows there might be a possibility to chose
differently (I believe that means it ignores the smaller units in this
case).

> There is even an example in the docstring:
>
>   The following format
>
>     ((\"d\" . nil) (special . h:mm))

Except the default really is shown as (("d") (special . h:mm)) if the
user cares to look things up.

>   means that any duration longer than a day is expressed with both
>   a \"d\" unit and a \"H:MM\" part, whereas a duration shorter than
>   a day is expressed only as a \"H:MM\" string.
>
> Basically,
>
>   1d 8:30
>
> is mixed mode.
>
>> and what happens if I specify both (special . h:mm) and ("h" . nil)
>> for instance. Is the order of these important?
>
> Specifying both (special . h:mm) and ("h" . nil) is nonsensical, since
> you request something like "0:30" in the first case, and "0h" in the
> second one.
>
> In this case, I think ("h" . nil) is going to be ignored since (special
> . h:mm) already takes care of hours an minutes.

I've picked something that I expected to be nonsensical on purpose,
although I think it wouldn't be entirely unreasonable for a user to
expect that the duration would simply get formatted both ways.  The
documentation should tell me not to do that or if it's ignoring part of
the specification.  I take from your answer that the order of
specification might not be important, but it's not spelled out in the
docstring yet.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra




reply via email to

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