emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Axel Kielhorn <org-mode@axelkielhorn.de>
Cc: Org-Mode Mailing List <emacs-orgmode@gnu.org>
Subject: Re: Updating column view dynamic block does not work with {est+}
Date: Thu, 20 May 2021 22:15:32 +0200	[thread overview]
Message-ID: <87cztlyxej.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <07BFE527-63BA-4B2E-8891-D668F8C4D93F@axelkielhorn.de> (Axel Kielhorn's message of "Thu, 20 May 2021 21:10:42 +0200")

Axel Kielhorn <org-mode@axelkielhorn.de> writes:

>> Am 20.05.2021 um 19:58 schrieb Nicolas Goaziou <mail@nicolasgoaziou.fr>:
>> 
>> Org Duration is strict about what it is fed with (which is good). Effort
>> property expects a duration as value. But "3-8" is not a valid duration.
>> However, "3" is a valid duration; it means 3 minutes.
>
> The problem is that effort can either be a duration and in that case the strict duration library ist fine.
> Or it can be a range (of days).

No, it means minutes. However, units do not matter in "est+". You can
interpret the result in days if it matters.

> 3:30 is fine when : is used to add the times
> 3.0 - 4.0 is a range estimate when est+ is used
> 3:00 - 4:00 is only correct by chance, 3:30 - 4:30 will lead to the
> same result since est+ does not handle durations.

This is what I'm suggesting, isn't it?

> Splitting it into 2 properties (effort and effort_range) is even worse
> since it will be inconsistent after a few edits.

This is _not_ what I'm suggesting.

> It gets even more interesting when on task has 3-4 (implicit) days, while another has 8:00 (implicit) hours.
> (Are 8 h one work day, or are 24 h one calendar day?)

Org Duration library is able to distinguish canonical from user-provided
units (see last argument in `org-duration-to-minutes). Actually, Org
Colview makes this distinction by calling "canonical" duration an "age"
(see "@min" and other operators).

There could be est+ and est-age+ (or anything else, really).

>> Maybe Effort property should simply accept a duration or a duration
>> range.
>
> That’s what I first thought it would do, since a duration is a time (8:00 for 8h).
> The question is how to resolve ambiguity?

I don't see any ambiguity. est+ can be changed to accept 2d-3d.

> 1.0 is one day

No, it's one minute. 1.0d is one day.

> 1:00 is one hour
> 1 is one minute, really? yes, that is the default for the duration
> library. But it used to mean one day???

A long time ago, yes, but that was inconsistent.

> Maybe a new est: function to work with durations and the old est+ function to work with numbers 
> (which could mean days, but it could mean ms as well)? And a warning about inconsistent units.

I don't think this is needed. The current est+ is not working anyway.

> What happens when I use a range in a clock table?

Who knows? :)

> But since the feature is advertised it would be great if it works.

There's no reason it cannot work. It just needs some love.

Regards,


      reply	other threads:[~2021-05-20 20:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-16  5:51 Updating column view dynamic block does not work with {est+} Axel Kielhorn
2021-05-20 17:12 ` Axel Kielhorn
2021-05-20 17:58   ` Nicolas Goaziou
2021-05-20 19:10     ` Axel Kielhorn
2021-05-20 20:15       ` 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=87cztlyxej.fsf@nicolasgoaziou.fr \
    --to=mail@nicolasgoaziou.fr \
    --cc=emacs-orgmode@gnu.org \
    --cc=org-mode@axelkielhorn.de \
    /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).