On Thu, 14 Feb 2013 07:12:38 +0200 Eli Zaretskii wrote: >> From: Stephen Berman >> Cc: 13690@debbugs.gnu.org >> Date: Thu, 14 Feb 2013 00:18:30 +0100 >> >> > . scroll-conservatively being non-nil >> >> I think you mean non-zero, since only integer values are admissible. >> But when scroll-conservatively is zero, recentering happens anyway, so I >> don't see the point of adding this condition. Or is there a problem is >> if recentering happens twice (once directly from the display engine and >> once by explicitly calling recenter)? I don't notice any problem. > > Why recenter twice? It's a waste of cycles. Ok. >> > . perhaps also scroll-margin being zero, because otherwise you get >> > several lines of context before point >> >> I tested scroll-margin and found no difference in the behavior of Info-up >> whether it is zero or non-zero; do you see something different? > > Do you have the latest trunk? If so, you should see a difference: > when scroll-margin is N, typing 'u' puts the line with cursor N+1 > lines from the top. Ah, I just updated and now see it (my previous build was a couple of days too old). However, I would prefer for Info-up to recenter even if scroll-margin is non-zero. When using C-p or C-n, I can well imagine wanting the display to start scrolling before point reaches the top or bottom of the window, i.e., I might want to set scroll-margin to a non-zero value. But when I type `u' in Info, I really want to see as much of the superior node as possible, not just one or two lines above the target line. If scroll-margin obeyed SCROLL_LIMIT like scroll-conservatively does (or perhaps a different limit just for scroll-margin), this would allow more flexibility. But in default of that, and not wanting to complicate things with another user option (at least until someone screams bloody murder), I would rather omit the scroll-margin check for now. 2014-02-13 Stephen Berman * info.el (Info-up): If scroll-conservatively is non-zero and less than 101, display as much of the superior node above the target line as possible. (Bug#13690)