bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#34723: 27.0.50; customize and improve diff-mode recentering


From: Charles A. Roelli
Subject: bug#34723: 27.0.50; customize and improve diff-mode recentering
Date: Sat, 16 Mar 2019 21:21:40 +0100

> From: Stefan Monnier <address@hidden>
> Date: Wed, 13 Mar 2019 15:40:16 -0400

> > The current implementation seems a little too eager.
> 
> Sometimes it's also not eager enough (if the hunk is longer than half of
> the screen, it shouldn't just recenter but it should likely scroll
> further so that more than half of the screen shows the hunk).

Yes.  In that specific case, we could call (recenter 0) to make more
(or all of) the hunk visible.
 
> > Yes, I think you are right.  Maybe diff-mode could have just set
> > scroll-conservatively (or scroll-margin) in a buffer-local variable to
> > get this auto-recentering behavior, although that would also step on
> > user customizations.
> 
> Not sure what you mean.  I have scroll-conservatively set to 0.
> How should I set it to get the recentering that I want?

Setting scroll-conservatively to 0 in diff-mode would of course not be
enough to recenter in all the cases where diff-hunk-next currently
does, but it would be a bit cleaner.  The part of the code that
recenters based on the visibility of the end of the hunk at point
could instead go in a post-command-hook (or in a display hook?), which
would make it work after all movement commands, not just
diff-hunk-next.  I don't know if that's desirable, though.

> As for scroll-margin, I don't like using it.  Also it would affect all
> cursor movement rather than only diff-hunk-* and would force point
> closer to the middle which is not what I want when the hunk is longer
> than half the window.

Agreed.

> In your original message you said:
> > We found that this behavior does not respect scroll-related variables
> 
> Did that only refer to `scroll-conservatively`?  If not, could you
> clarify which scroll-related variable setting is not respected,
> and when?

Hm, I'm not sure if there was another variable that the behavior
affects (can't find one now).  This is no big issue; it's an argument
for making the behavior customizable.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]