I was just working on https://list.orgmode.org/orgmode/87wn31up0d.fsf@localhost/ as a simple bug to tackle, but now that I'm catching up on this thread should I wait until some of the timestamp handling here has been addressed? I have a patch ready for `org-timestamp-change' that I think is probably independent of what you're discussing, but I can wait if it would complicate the current review.
Cheers, Derek On Sat, Apr 4, 2026 at 6:13 AM Ihor Radchenko <[email protected]> wrote: > Morgan Smith <[email protected]> writes: > > > Well, it turns out the code in `org-clock-timestamps-change' does a lot > of > > sketchy point shenanigians and I'm actually still not certain why that > case > > fails. While investigating I found slightly different cases that failed > so I > > decided to just rewrite it as that felt easier. > > I am not surprised. Timestamp change functions (also > `org-timestamp-change') do a lot of weird staff and are most likely > broken in edge cases. I was just not dare to touch them as it could > introduce new bugs. > > > Also, I just want to point out something crazy sketchy that this function > > currently does (without my patch). > > > > Open a new org-mode buffer and put two timestamps in that buffer on > seperate > > lines like this: > > > > [2026-03-29 Sun] > > [2026-03-29 Sun] > > > > Now put your point on the first one and try calling > `org-clock-timestamps-up' > > and `org-clock-timestamps-down'. It modifies the one on the second line > as > > well!!! That's a big nono!!! > > > > See attached for a better implementation. > > Thanks! > > > + (setq n (prefix-numeric-value n)) > > I think that is a wrong place to do it. > According to the docstring "Optional argument N tells to change by that > many units.", so it should already be a number. > We need to fix the callers instead. > > > + (let ((original-point (point)) > > Better use marker or something, I think. > `org-timestamp-change' can change nearby clocks, leading to point being > completely off. > > > + (move-beginning-of-line 1) > > If we are rewriting this anyway, better use (forward-line 0). That will > ignore fields and invisible text. > > > + (looking-at regex) > > So, what will happen if we are not on a clock entry, and there are three > or more timestamps on the current line? > > [2026-04-04 Sat] [2026-04-04 Sat] [2026-04<point>-04 Sat] > > And what if we are at diary sexp timestamp? > > > + (goto-char (1+ (match-beginning 1))) > > + (org-timestamp-change tschange timestamp? 'updown) > > + (when (looking-at regex) > > This will search for the next timestamp following the changed timestamp. > What if that's not a clock? > > [2026<point>-04-04 Sat] [2026-04-04 Sat] > > -- > Ihor Radchenko // yantar92, > Org mode maintainer, > 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> > > -- +---------------------------------------------------------------+ | Derek Chen-Becker | | GPG Key available at https://keybase.io/dchenbecker and | | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org | | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7 7F42 AFC5 AFEE 96E4 6ACC | +---------------------------------------------------------------+
