emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Achim Gratz <Stromeko@nexgo.de>
Cc: emacs-orgmode@gnu.org
Subject: Re: [ANN] New Org duration library
Date: Wed, 22 Feb 2017 20:01:17 +0100	[thread overview]
Message-ID: <87k28if3sy.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <87a89etf2y.fsf@trex> (Aaron Ecay's message of "Wed, 22 Feb 2017 15:33:57 +0000")

Hello,

Aaron Ecay <aaronecay@gmail.com> writes:

> I had a few questions/comments though:
>
> - Given that the smallest unit of duration is the minute,

The base unit is the minute, but nobody prevents you from adding
a smaller unit:

  (let ((org-duration-units (cons `("s" . ,(/ 1 60.0)) org-duration-units)))
    (org-duration-from-minutes 1.5 '(("min") ("s"))))

  => "1min 30s"

>   why are seconds a choice in h:mm:ss?  Wonʼt they always be zero?

Internally, durations are floats because of seconds.

  (org-duration-from-minutes 1.5 'h:mm:ss) => "0:01:30"

>   Maybe it is
>   better not to offer this choice; I think it is potentially confusing
>   (giving the impression that durations might be accurate to the
>   second).

Durations _can_ be accurate to the second. This library can be used
outside clocksum computations, which are, indeed, accurate only to the
minute.

> - I would remove the h:mm symbol shorthand.  It can still be offered as
>   a convenient option in customize using (const :tag "Use H:MM" (special
>   . h:mm)), but making it a special value with its own semantics makes
>   the system harder to understand for those who write their config in
>   lisp (rather than using customize).

Using a list means you want to use special units to display the
duration. However when the value is '((special . h:mm)), there is no
unit to display the duration with, so '((special . h:mm)) is the
degenerate case, not `h:mm'.

Mind you, I'm not opposed to removing `h:mm'. I'm just pointing out the
rational behind the initial choice.

Moreover, if we remove `h:mm', we need to replace calls like

  (org-duration-from-minutes 120 'h:mm)

with

  (org-duration-from-minutes 120 '((special . h:mm)))

which is slightly uglier.

> - The fact that the special options are grouped under the key “special”
>   is a bit confusing.  If it isnʼt too much work, I would recommend
>   restructuring the options slightly to be (use-h:mm . t) and (precision
>   . INT).  This more closely matches my intuition about how alists like
>   this are used.

I chose `special' for a reason: these options are mutually exclusive.
Using the same key, the structure (i.e., the alist) makes them mutually
exclusive, too. With your suggestion, however, nothing prevents an user
to have

  '((use-h:mm . t) (precision . 2))

and complain if strange things happen.

So, I'd rather keep the same car. I'm not married to `special' though.

> - Must the list be in decreasing order of unit size, or does everything
>   work if itʼs in arbitrary order?  The documentation doesnʼt make it
>   clear one way or the other.

There is no restriction about the order.

> The value should be a list of entries each following this pattern:
>
>   (UNIT . REQUIRED)

I'd favor REQUIRED? over REQUIRED because it is a boolean.

> UNIT is one of the unit strings defined in `org-duration-units'.  A
> duration is formatted using only the time components that are specified
> here.  If a time unit in missing, formatting falls back to the next
> smallest unit.

The algorithm works the other way: it consider biggest units first
(greedy algorithm).

> At the end of the list, there can be an entry indicating special formatting

"The end of the list" is not accurate. The entry can be anywhere.

Also, I reworded that part already in master. You may want to have
a look at it.

Regards,

-- 
Nicolas Goaziou                                                0x80A93738

      reply	other threads:[~2017-02-22 19:01 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
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 [this message]

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=87k28if3sy.fsf@nicolasgoaziou.fr \
    --to=mail@nicolasgoaziou.fr \
    --cc=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).