> 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 <k...@kyleam.com>: > > Dmitrii Korobeinikov <dim12...@gmail.com> 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.
