Re: org-clock misleading description for a prompt option

[Dmitrii Korobeinikov]

> That seems confusing to me as well (at least being the not-advanced
> clocker that I am).  I suspect the confusion comes from the different
> perspective from which it's written.  You're talking about restarting
> Emacs and clocking in again; the description is, I think, written
> assuming the context of the prompt being triggered due to idle time.  In
> that scenario, hitting i/q or 'k => all' have the same effect; a new
> entry is not created.

I am not sure I follow. Is idle time some sort of concept used by
org-clock for something more than the interface explanations?

Whether I restart emacs or purposefully insert (while no clocks are
running) `CLOCK: [2020-04-10 Fri 22:43]' into a logbook and do
org-clock-in, the behaviour is the same. Also, 'k => all' is not an
option for me, it just asks for a number, defaulting to the elapsed
time. Perhaps it's because I am running an older version of org-mode
(9.3.6.)

пт, 10 апр. 2020 г. в 10:47, Kyle Meyer <address@hidden>:
>
> Dmitrii Korobeinikov <address@hidden> writes:
>
> > When you run org-clock-in and then restart emacs, clocking in again
> > will show a prompt asking what to do w/ the unfinished entry. "i"
> > means "ignore this question; the same as keeping all the idle time".
> > However, a new entry is created if this is chosen without doing
> > anything about unfinished one. Keeping all the idle time w/ "k"
> > updates the unfinished entry before starting a new one. "i" doesn't do
> > that, so the description seems a bit misleading.
>
> That seems confusing to me as well (at least being the not-advanced
> clocker that I am).  I suspect the confusion comes from the different
> perspective from which it's written.  You're talking about restarting
> Emacs and clocking in again; the description is, I think, written
> assuming the context of the prompt being triggered due to idle time.  In
> that scenario, hitting i/q or 'k => all' have the same effect; a new
> entry is not created.
>
> This resolving on clock-in vs resolving when idle discrepancy shows in
> at least one other part of the description: the final sentence says that
> the uppercase variants leads to a clocked out state, but that's not true
> when org-clock-resolve is triggered from an org-clock-in call.
>
> So, while I think things could be improved here (contributions welcome),
> those changes should keep both contexts in mind.