emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [O] Bug: Inconsistent effort handling in clock totals in maint [9.1.


From: Bernt Hansen
Subject: Re: [O] Bug: Inconsistent effort handling in clock totals in maint [9.1.13 (release_9.1.13 @ /home/bernt/git/org-mode/lisp/)]
Date: Mon, 14 May 2018 11:52:24 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

Nicolas Goaziou <address@hidden> writes:

> Bernt Hansen <address@hidden> writes:
>
>> I am fine with plain numbers being interpretted as hours. I don't
>> think we need a second interpretation for it (as minutes).
>
> The second interpretation already exists. "org-colview.el" is the sole
> place where plain numbers are treated as hours. Everywhere else, plain
> numbers are minutes, including in "org-clock.el".
>

OK

I wasn't aware that column view is the only place in org-mode where
plain effort numbers mean hours.  So then if we change anything making
column view in line with the rest of org-mode would get my vote.

>> I don't think changing a bare 15 effort to mean minutes instead of the
>> hours is a good idea - in case existing users already have effort data
>> with plain numbers -- their estimates will change drastically.
>
> I'm not proposing to change anything. I'm just suggesting a new way to
> let users decide what should mean "15" when summing properties in
> Columns View mode.
>
> The issue here is you don't want to change Columns View mode, but
> everything else. Or, more accurately, you want to add another exception
> in plain numbers handling when displaying the mode line. This means
> changing how `org-duration-to-minutes' interprets plain numbers, hence
> the "everything else" part.
>
>> Ideally I think I just want the mode line total to behave the same as
>> the existing column view behaviour as far as plain numbers are concerned
>> if this is easy and not causing more problems than it fixes.
>
> We shot ourselves in the foot when we decided that one part of Org
> should consider plain numbers as minutes and the other part as hours.
> This is clearly sub-optimal.
>
> I see no easy way to fix it painlessly. If we change anything, the
> easier route to go is having Column View mode consider plain numbers as
> minutes, because it only affects ... Column View mode itself.
>

I'd like to change my vote :)
So Cancel the above request about touching the mode line code :)

> We can also change nothing. I have the feeling this issue will bubble up
> from time to time, though.
>
> WDYT?

Okay that all sounds very reasonable :)

I think changing column view to be consistent with the rest of org-mode
is the right way to go if we are changing anything.

The issue is how to alert any users in the wild that are already using
efforts and expecting it to behave as hours in column mode so they can
fix their data if we change the interpretation from hours to minutes to
match the rest of org-mode.

I expect this is really old behaviour and a fix isn't really required.

Personally I will try to move away from using plain numbers as efforts.
I usually mean minutes but will need to fix any values that are
displayed in column mode.

For now I will just find and fix my effort values in my org-files and
try not to create plain numbers as efforts in the future when they are
used in column mode.

My org files are under a git repository so finding the bad entries is
fairly easy for me:

git grep -nHi ':effort:' | grep -v '[0-9]:[0-9]'

Would it be useful to flag plain effort numbers in org-lint so they are
easier to find and fix?  This way if I make more in the future I will
hopefully notice sooner.  I have some zero (0) entries and some empty
entries in my org files -- but maybe that's okay.

>> Otherwise I can live with it -- it's been this way for years I think --
>> and I will just change my effort values to always include both HH:MM and
>> avoid plain numbers.
>
> That's the most reasonable solution, IMO. Note that you can also use
> "3h" instead of the ambiguous "3".

Thanks - I wasn't aware of that option.

So unless someone else feels strongly about this issue we should just
close this bug report and 'do nothing'.

Thanks for listening :)

Regards,
Bernt



reply via email to

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