S-M-{<UP>,<DOWN>} on CLOCK timestamp

S-M-{<UP>,<DOWN>} on CLOCK timestamp

[Jorge P. de Morais Neto]

Keywords: org-timestamp-down org-timestamp-up

Hi.  Suppose the buffer has the following text:

* Task A
:LOGBOOK:
CLOCK: [2021-08-21 sáb 18:00]--[2021-08-21 sáb 18:10] =>  0:10
:END:

* Task B
:LOGBOOK:
CLOCK: [2021-08-21 sáb 18:18]
:END:

If I invoke M-S-<down> on Task B's clock-in timestamp, with point right
after the colon that separates HH from MM, then it correctly changes to
18:15 (decreases by three minutes), but Task A's clock-out timestamp
changes to 18:05---decreases by *five* minutes.

In my opinion, in this case the previous clock-out timestamp should not
change at all, because it was already less than 18:15.  But even if you
do think it should change, then surely you at least agree that it should
change by *three* minutes, just like Task A's clock-in timestamp.

This occurs on GNU Emacs 28.0.50 installed with
~guix package --with-branch=emacs-next=master -i emacs-next~
(upgraded last Thursday morning), invoked as ~emacs -Q~.  Note that on
my Guix-installed Emacs, an ~emacs -Q~ does load the emacs-org Guix
package (version 9.4.6).  Note also that my Org Mode has been patched
with Ihor Radchenko's patch to org-clock.el (attached to my previous
message), but it clearly can't influence this problem.

Regards

Emacs  : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
Package: Org mode version 9.4.6 (9.4.6-gab9f2a @ /gnu/store/yg6kjzigqyfzbkzj99xmwmv3nssvhvnq-emacs-org-9.4.6/share/emacs/site-lisp/org-9.4.6/)

-- 
- Disinformation flourishes because many people care about injustice
  but very few check the facts.  Ask me about <https://stallmansupport.org>
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- Free Software Supporter: https://www.fsf.org/free-software-supporter
- If an email of mine arrives at your spam box, please notify me.

Re: S-M-{<UP>,<DOWN>} on CLOCK timestamp

[Tim Cross]

"Jorge P. de Morais Neto" <jorge+list@disroot.org> writes:

> Keywords: org-timestamp-down org-timestamp-up
>
> Hi.  Suppose the buffer has the following text:
>
> * Task A
> :LOGBOOK:
> CLOCK: [2021-08-21 sáb 18:00]--[2021-08-21 sáb 18:10] =>  0:10
> :END:
>
> * Task B
> :LOGBOOK:
> CLOCK: [2021-08-21 sáb 18:18]
> :END:
>
> If I invoke M-S-<down> on Task B's clock-in timestamp, with point right
> after the colon that separates HH from MM, then it correctly changes to
> 18:15 (decreases by three minutes), but Task A's clock-out timestamp
> changes to 18:05---decreases by *five* minutes.
>
> In my opinion, in this case the previous clock-out timestamp should not
> change at all, because it was already less than 18:15.  But even if you
> do think it should change, then surely you at least agree that it should
> change by *three* minutes, just like Task A's clock-in timestamp.
>
> This occurs on GNU Emacs 28.0.50 installed with
> ~guix package --with-branch=emacs-next=master -i emacs-next~
> (upgraded last Thursday morning), invoked as ~emacs -Q~.  Note that on
> my Guix-installed Emacs, an ~emacs -Q~ does load the emacs-org Guix
> package (version 9.4.6).  Note also that my Org Mode has been patched
> with Ihor Radchenko's patch to org-clock.el (attached to my previous
> message), but it clearly can't influence this problem.
>
> Regards
>
> Emacs  : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
> Package: Org mode version 9.4.6 (9.4.6-gab9f2a @
> /gnu/store/yg6kjzigqyfzbkzj99xmwmv3nssvhvnq-emacs-org-9.4.6/share/emacs/site-lisp/org-9.4.6/)


I cannot reproduce this.

When I do the same, I don't see any change in Task A's timestamp at all.
There must be some other setting in play here which I don't have.

Re: S-M-{<UP>,<DOWN>} on CLOCK timestamp

[Jorge P. de Morais Neto]

Hello Tim!

Em [2021-08-22 dom 11:21:47+1000], Tim Cross escreveu:

> I cannot reproduce this.
>
> When I do the same, I don't see any change in Task A's timestamp at all.
> There must be some other setting in play here which I don't have.

I am sorry, my description of the initial condition was incomplete.  To
reproduce the problem, you cannot simply copy the provided text to an
Org buffer.  You should create the clock timestamps with actual clocking
commands.  So please do the following:

1. In an Org buffer, create an outline containing ~Task A~ and ~Task B~:

   --8<---------------cut here---------------start------------->8---
   * Task A

   * Task B
   --8<---------------cut here---------------end--------------->8---

2. Clock into Task A by moving point to it and typing C-c C-x C-i.
3. Clock into Task B by moving point to it and typing C-c C-x C-i.
4. Increase the minutes part of task B's clock-in timestamp via C-u 42
   S-<up>¹.  The ~42~ numeric prefix is just an example; please choose
   the numeric prefix argument so that:
   1. It is at least 5
   2. The resulting time in the timestamp is *not* a multiple of 5 min.
5. If the minutes part of task A's clock out time is not already a
   multiple of 5, then hit S-<up>¹ (no prefix argument) to make it so.
6. Now you can reproduce the problem.

¹ When you are about to type S-<up> to adjust the minutes part of a
clock timestamp, make sure point is in the minutes part you want to
adjust.  I usually place point right after the colon that separates HH
from MM.

Regards!

-- 
- Disinformation flourishes because many people care about injustice but
  very few check the facts.  Ask me about <https://stallmansupport.org>
- Please adopt free/libre formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
- Free/libre software for Replicant, LineageOS and Android: https://f-droid.org
- https://www.gnu.org/philosophy/free-sw.html "What is free software?"

Re: S-M-{<UP>,<DOWN>} on CLOCK timestamp

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 416 bytes --]

Hi Tim,

Jorge P. de Morais Neto <jorge+list@disroot.org> writes:

> I am sorry, my description of the initial condition was incomplete.  To
> reproduce the problem, you cannot simply copy the provided text to an
> Org buffer.  You should create the clock timestamps with actual clocking
> commands.  So please do the following:

> *snip*

Have you had a chance to try reproducing this again?

All the best,
Timothy

Re: S-M-{<UP>,<DOWN>} on CLOCK timestamp

[Tim Cross]

Timothy <tecosaur@gmail.com> writes:

> Hi Tim,
>
> Jorge P. de Morais Neto <jorge+list@disroot.org> writes:
>
>> I am sorry, my description of the initial condition was incomplete.  To
>> reproduce the problem, you cannot simply copy the provided text to an
>> Org buffer.  You should create the clock timestamps with actual clocking
>> commands.  So please do the following:
>
>> *snip*
>
> Have you had a chance to try reproducing this again?
>

No I've not. I started to, got distracted with another task and never
got back to it. I'll see if I can find time later this week. 

Re: S-M-{<UP>,<DOWN>} on CLOCK timestamp

[Tim Cross]

Timothy <tecosaur@gmail.com> writes:

> Hi Tim,
>
> Jorge P. de Morais Neto <jorge+list@disroot.org> writes:
>
>> I am sorry, my description of the initial condition was incomplete.  To
>> reproduce the problem, you cannot simply copy the provided text to an
>> Org buffer.  You should create the clock timestamps with actual clocking
>> commands.  So please do the following:
>
>> *snip*
>
> Have you had a chance to try reproducing this again?
>

I'm now confused over this bug report. Originally, two similar bugs were
reported at the same time. I was able to confirm one and not the other.
The added instructions seem to be a hybrid of the two bug reports, so
I'm now confused and not sure on what was the precise bug for the second
report. Based on what I *think* was the second bug, I cannot reproduce
it, but I have little confidence in that.

Re: S-M-{<UP>,<DOWN>} on CLOCK timestamp

[Jorge P. de Morais Neto]

[-- Attachment #1: Type: text/plain, Size: 680 bytes --]

Hello Timothy, Tim, everyone!  I apologize for the delay and (finally)
reply below:

Em [2021-09-25 sáb 08:22:43+1000], Tim Cross escreveu:

> I'm now confused over this bug report. Originally, two similar bugs
> were reported at the same time.  I was able to confirm one and not the
> other.  The added instructions seem to be a hybrid of the two bug
> reports, so I'm now confused and not sure on what was the precise bug
> for the second report.  Based on what I *think* was the second bug, I
> cannot reproduce it, but I have little confidence in that.

My (English) writing skills seem to be failing me, so I made an animation
with the gif-screencast package:

[-- Attachment #2: Bug when adjusting Org Mode clock timestamps --]
[-- Type: image/gif, Size: 406216 bytes --]

[-- Attachment #3: Type: text/plain, Size: 2380 bytes --]


A textual description:

1. Begin with an empty Org Mode buffer
2. Create a heading "Task A"
3. Clock in
4. Open the LOGBOOK drawer
5. Adjust the clock in timestamp with S-<down> on the MM (minutes) part
   so it ends with 0 (that is, it is a multiple of 10).  You may have to
   press S-<down> multiple times.
6. Clock out
7. Adjust the clock out timestamp with S-<down> on the MM (minutes) part
   so it ends with 5 (so it is a multiple of 5 but not of 10) and is
   larger than the clock in timestamp.  Again, you may have to press
   S-<down> multiple times.
8. Create another heading (with C-<return>): "Task B"
9. Clock into Task B
10. Open Task B LOGBOOK drawer
11. Clock out
12. Check if Task B clock in timestamp is not a multiple of 5.  In the
    animation I was lucky, it already wasn't a multiple of 5¹.
13. Finally, adjust Task B's clock in timestamp with M-S-<down> on the
    MM (minutes) part.  Bug!

The bug is that M-S-<down> adjusts Task B clock in timestamp by x
minutes and Task A clock out timestamp by 5 minutes, where x (in our
case, x is 4) is not 5.  And in my opinion, Task A clock out timestamp
*should not change at all* because it was already less then the adjusted
Task B clock in timestamp.

For convenience I generated the animation from my fully configured
Emacs, but I have verified it also occurs on Emacs -Q.  My Emacs was
compiled and installed via Guix from the emacs-28 branch.  I currently
use the native comp feature (via flatwhatson's Guix channel) but I
previously reproduced the bug on vanilla Guix's emacs-next (only
compiled with --with-branch=emacs-next=emacs-28).

Regards!

PS: Have I violated netiquette by directly attaching the animation?  I
judged it was OK because the file is only 406kB.

¹ If Task B clock in timestamp was a multiple of 5 then we would have to
adjust it with S-<down> with a numeric prefix argument (that itself must
not be a multiple of 5), taking care to keep it larger than Task A clock
out timestamp.

-- 
- Many people hate injustice but few check the facts.  This provokes
  misinformation.  Ask me about <https://stallmansupport.org>
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- Free Software Supporter: https://www.fsf.org/free-software-supporter
- If an email of mine arrives at your spam box, please notify me.

Re: S-M-{<UP>,<DOWN>} on CLOCK timestamp

[Ihor Radchenko]

Jorge P. de Morais Neto <jorge+list@disroot.org> writes:

> A textual description:
>
> ...
> The bug is that M-S-<down> adjusts Task B clock in timestamp by x
> minutes and Task A clock out timestamp by 5 minutes, where x (in our
> case, x is 4) is not 5.  And in my opinion, Task A clock out timestamp
> *should not change at all* because it was already less then the adjusted
> Task B clock in timestamp.

Confirmed.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>