Follow Emacs' own scrolling variables when moving the cursor

[demoj1]

Good point, I agree — a separate option was the wrong call. Rewritten to use the variables the user already has.

scroll-margin now says how close to the edge the cursor may come. It is counted in cursor slots, which are the calendar's screen lines, and maximum-scroll-margin caps it exactly as it does in Emacs.

scroll-conservatively decides what happens at the margin: scroll just enough when it is positive, recentre otherwise. So your example works as expected — with scroll-margin at 10 and scroll-conservatively at 0 the calendar starts scrolling ten slots from the edge and recentres when it does, which is what the same settings do in an ordinary buffer.

Note this changes the default behaviour a little: with stock settings (scroll-conservatively is 0) the calendar now recentres when the cursor leaves the view, instead of always scrolling the minimum. That is what Emacs itself does by default, so I think it is the right default here too — but say the word if you would rather keep the old minimal scrolling as the fallback.

org-timegrid-scroll-style is gone. What is left from the original PR is the shared org-timegrid--center-cursor, which org-timegrid-recenter now uses as well.

The branch is rebased on current main. Tests: 25 pass, one is new and checks the margin against both scroll-margin and the maximum-scroll-margin cap.

[Gleek]

Thanks for the idea and the PR!
The refactoring around org-timegrid--center-cursor looks useful, but I wonder whether we should reuse Emacs’s existing scrolling configuration instead of introducing org-timegrid-scroll-style.

Although the timegrid cursor is rendered inside the SVG, we can treat the standard variables as a scrolling policy and apply the resolved result through org-timegrid--set-vscroll.

For example, if a user has configured Emacs to start scrolling when the cursor is within ten lines of the window edge and to recenter it when scrolling occurs, the calendar cursor should behave the same way. This would make keyboard navigation feel consistent with the rest of Emacs without requiring separate timegrid configuration.

The relevant variables could be:

• scroll-margin
• maximum-scroll-margin
• scroll-conservatively
• scroll-step
• scroll-up-aggressively
• scroll-down-aggressively

Would you be interested in adapting this PR in that direction? WDYT?

[demoj1]

Good point, I agree — a separate option was the wrong call. Rewritten to use the variables the user already has.

scroll-margin now says how close to the edge the cursor may come. It is counted in cursor slots, which are the calendar's screen lines, and maximum-scroll-margin caps it exactly as it does in Emacs.

scroll-conservatively decides what happens at the margin: scroll just enough when it is positive, recentre otherwise. So your example works as expected — with scroll-margin at 10 and scroll-conservatively at 0 the calendar starts scrolling ten slots from the edge and recentres when it does, which is what the same settings do in an ordinary buffer.

Note this changes the default behaviour a little: with stock settings (scroll-conservatively is 0) the calendar now recentres when the cursor leaves the view, instead of always scrolling the minimum. That is what Emacs itself does by default, so I think it is the right default here too — but say the word if you would rather keep the old minimal scrolling as the fallback.

org-timegrid-scroll-style is gone. What is left from the original PR is the shared org-timegrid--center-cursor, which org-timegrid-recenter now uses as well.

The branch is rebased on current main. Tests: 25 pass, one is new and checks the margin against both scroll-margin and the maximum-scroll-margin cap.

[Gleek]

This is closer to what I had in mind, but don't think it correctly does it.

Were you able to do some usability testing. I mean apart from the running the generated test case.

I suppose we should try different values for these variables and test scrolling in normal emacs buffer and then do the same in the timegrid. If they "feel" the same then we're probably on the right track.

[Gleek]

This is not how scroll-conservatively works. We seem to be treating it as a boolean.
This is the doc:

Scroll up to this many lines, to bring point back on screen.

If point moves off-screen, redisplay will scroll by up to
scroll-conservatively lines in order to bring point just barely
onto the screen again.  If that cannot be done, then redisplay
recenters point as usual.

If the value is greater than 100, redisplay will never recenter point,
but will always scroll just enough text to bring point into view, even
if you move far away.

A value of zero means always recenter point if it moves off screen.

[Gleek]

what are we doing here? Seems unnecessary (and also wrong?)
1.0 would become 0.5
-0.1 would become 0
1 becomes 0.5

In all these cases emacs would treat it as 0.25 instead.

[Gleek]

This doesn't look very useful. We should add tests that do actual scrolling with different config values and see if the expectations satisfy. Example keeping the cursor centered, stuck to the top / bottom, 10 rows above the bottom, etc.

[Gleek]

Also a quick heads up. I prefer direct, concise developer notes over AI-polished responses. It helps me understand your exact intent faster and calibrate how deeply I need to audit the logic 😄 . Thanks for understanding.