From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: Re: [ANN] New Org duration library Date: Tue, 21 Feb 2017 20:47:00 +0100 Message-ID: <87r32rtjgr.fsf@Rainer.invalid> References: <87bmu6p4f5.fsf@nicolasgoaziou.fr> <87h93nxxs4.fsf@Rainer.invalid> <8760k3toq2.fsf@nicolasgoaziou.fr> <87d1ebxv29.fsf@Rainer.invalid> <87d1ebgyy1.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49479) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cgGP6-0004ey-5b for emacs-orgmode@gnu.org; Tue, 21 Feb 2017 14:47:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cgGP3-0008U6-19 for emacs-orgmode@gnu.org; Tue, 21 Feb 2017 14:47:16 -0500 Received: from [195.159.176.226] (port=40759 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cgGP2-0008Te-PK for emacs-orgmode@gnu.org; Tue, 21 Feb 2017 14:47:12 -0500 Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cgGOs-0004ur-8Y for emacs-orgmode@gnu.org; Tue, 21 Feb 2017 20:47:02 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: emacs-orgmode@gnu.org 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