emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Bernt Hansen <bernt@norang.ca>
To: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Cc: emacs-orgmode@gnu.org
Subject: Re: 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	[thread overview]
Message-ID: <874ljaqlon.fsf@norang.ca> (raw)
In-Reply-To: <877eo6z9pa.fsf@nicolasgoaziou.fr> (Nicolas Goaziou's message of "Mon, 14 May 2018 14:46:25 +0200")

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Bernt Hansen <bernt@norang.ca> 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	other threads:[~2018-05-14 15:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-12  4:33 Bug: Inconsistent effort handling in clock totals in maint [9.1.13 (release_9.1.13 @ /home/bernt/git/org-mode/lisp/)] Bernt Hansen
2018-05-13 21:36 ` Nicolas Goaziou
2018-05-14  0:53   ` Bernt Hansen
2018-05-14 12:46     ` Nicolas Goaziou
2018-05-14 15:52       ` Bernt Hansen [this message]
2018-06-19 14:35         ` Nicolas Goaziou
2018-06-19 15:31           ` Bernt Hansen

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=874ljaqlon.fsf@norang.ca \
    --to=bernt@norang.ca \
    --cc=emacs-orgmode@gnu.org \
    --cc=mail@nicolasgoaziou.fr \
    /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).