emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* org-clock misleading description for a prompt option
@ 2020-04-09 10:41 Dmitrii Korobeinikov
  2020-04-10  4:47 ` Kyle Meyer
  0 siblings, 1 reply; 5+ messages in thread
From: Dmitrii Korobeinikov @ 2020-04-09 10:41 UTC (permalink / raw)
  To: emacs-orgmode

Hi!

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.

Best,
DK


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: org-clock misleading description for a prompt option
  2020-04-09 10:41 org-clock misleading description for a prompt option Dmitrii Korobeinikov
@ 2020-04-10  4:47 ` Kyle Meyer
  2020-04-10 16:57   ` Dmitrii Korobeinikov
  0 siblings, 1 reply; 5+ messages in thread
From: Kyle Meyer @ 2020-04-10  4:47 UTC (permalink / raw)
  To: Dmitrii Korobeinikov; +Cc: emacs-orgmode

Dmitrii Korobeinikov <dim1212k@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.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: org-clock misleading description for a prompt option
  2020-04-10  4:47 ` Kyle Meyer
@ 2020-04-10 16:57   ` Dmitrii Korobeinikov
  2020-04-10 21:40     ` Kyle Meyer
  0 siblings, 1 reply; 5+ messages in thread
From: Dmitrii Korobeinikov @ 2020-04-10 16:57 UTC (permalink / raw)
  To: Kyle Meyer; +Cc: emacs-orgmode

> 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 <kyle@kyleam.com>:
>
> Dmitrii Korobeinikov <dim1212k@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.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: org-clock misleading description for a prompt option
  2020-04-10 16:57   ` Dmitrii Korobeinikov
@ 2020-04-10 21:40     ` Kyle Meyer
  2020-04-11 10:12       ` Dmitrii Korobeinikov
  0 siblings, 1 reply; 5+ messages in thread
From: Kyle Meyer @ 2020-04-10 21:40 UTC (permalink / raw)
  To: Dmitrii Korobeinikov; +Cc: emacs-orgmode

Dmitrii Korobeinikov <dim1212k@gmail.com> writes:

>> 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?

Yes, see

    (info "(org)Resolving idle time")

Even if you don't customize org-clock-idle-time, the option mentioned in
the second paragraph of that page, you can trigger that prompt manually
to account for being idle by calling org-resolve-clocks (bound to 'C-c
C-x C-z' by default).

> 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.

Right.  I'd say that falls into the same category as the restart.  The
key, as you mention, it that there is no clock running (versus a clock
running with idle time to account for).

> 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.)

Sorry for the unclear shorthand.  I just meant "hit k, select the
default value to keep all idle time".


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: org-clock misleading description for a prompt option
  2020-04-10 21:40     ` Kyle Meyer
@ 2020-04-11 10:12       ` Dmitrii Korobeinikov
  0 siblings, 0 replies; 5+ messages in thread
From: Dmitrii Korobeinikov @ 2020-04-11 10:12 UTC (permalink / raw)
  To: Kyle Meyer; +Cc: emacs-orgmode

Alright, I see. Thanks for the explanations!

сб, 11 апр. 2020 г. в 03:40, Kyle Meyer <kyle@kyleam.com>:
>
> Dmitrii Korobeinikov <dim1212k@gmail.com> writes:
>
> >> 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?
>
> Yes, see
>
>     (info "(org)Resolving idle time")
>
> Even if you don't customize org-clock-idle-time, the option mentioned in
> the second paragraph of that page, you can trigger that prompt manually
> to account for being idle by calling org-resolve-clocks (bound to 'C-c
> C-x C-z' by default).
>
> > 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.
>
> Right.  I'd say that falls into the same category as the restart.  The
> key, as you mention, it that there is no clock running (versus a clock
> running with idle time to account for).
>
> > 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.)
>
> Sorry for the unclear shorthand.  I just meant "hit k, select the
> default value to keep all idle time".


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2020-04-11 10:13 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-09 10:41 org-clock misleading description for a prompt option Dmitrii Korobeinikov
2020-04-10  4:47 ` Kyle Meyer
2020-04-10 16:57   ` Dmitrii Korobeinikov
2020-04-10 21:40     ` Kyle Meyer
2020-04-11 10:12       ` Dmitrii Korobeinikov

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).