From: Achim Gratz <Stromeko@nexgo.de>
To: emacs-orgmode@gnu.org
Subject: Re: [ANN] New Org duration library
Date: Tue, 21 Feb 2017 20:47:00 +0100 [thread overview]
Message-ID: <87r32rtjgr.fsf@Rainer.invalid> (raw)
In-Reply-To: 87d1ebgyy1.fsf@nicolasgoaziou.fr
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
next prev parent reply other threads:[~2017-02-21 19:47 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-13 14:10 [ANN] New Org duration library Nicolas Goaziou
2017-02-14 8:17 ` Detlef Steuer
2017-02-14 9:01 ` Nicolas Goaziou
2017-02-14 9:10 ` Detlef Steuer
2017-03-03 2:31 ` David Mann
2017-03-03 2:46 ` David Mann
2017-03-03 11:24 ` Nicolas Goaziou
2017-02-21 17:24 ` Achim Gratz
2017-02-21 17:53 ` Nicolas Goaziou
2017-02-21 18:22 ` Achim Gratz
2017-02-21 18:51 ` Nicolas Goaziou
2017-02-21 19:47 ` Achim Gratz [this message]
2017-02-22 10:56 ` Nicolas Goaziou
2017-02-22 11:50 ` Malcolm Purvis
2017-03-17 8:00 ` Nicolas Goaziou
2017-02-22 15:33 ` Aaron Ecay
2017-02-22 19:01 ` Nicolas Goaziou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r32rtjgr.fsf@Rainer.invalid \
--to=stromeko@nexgo.de \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).