On Wed, 13 Feb 2013 19:41:13 +0200 Eli Zaretskii wrote: >> From: Stephen Berman >> Cc: 13690@debbugs.gnu.org >> Date: Wed, 13 Feb 2013 14:36:58 +0100 >> >> > scroll-conservatively affects _any_ movement within a buffer, not just >> > to scrolling commands. >> >> I think this should be made clear in the documentation. In the Emacs >> Lisp manual, scroll-conservatively is only mentioned in the context of >> textual scrolling and there's no indication that it has wider scope. >> The variable's doc string doesn't say it only affects movement by >> scrolling, but given its name and the manual discussion, this is a >> plausible assumption, so its scope should also be made clear here. A >> less misleading name would also help, e.g. restore-point-conservatively. > > A name change is out of question at this point, I think, as this > option is very old. As for documentation, feel free to send patches > that clarify this. > > Note that the applicability of scroll-* options to movement that > doesn't necessarily look like "scrolling" is not limited to > scroll-conservatively. E.g., scroll-margin comes to mind. I don't feel confident I understand the intended behavior of these options well enough to formulate satisfactory doc. But I'll think about it some more and maybe make an attempt, which could then be refined. >> *** lisp/info.el 2013-02-01 16:46:46 +0000 >> --- lisp/info.el 2013-02-13 13:25:51 +0000 >> *************** >> *** 2246,2252 **** >> nil t)) >> (progn (beginning-of-line) (if (looking-at "^\\* ") (forward-char 2))) >> (goto-char p) >> ! (Info-restore-point Info-history))))) >> >> (defun Info-history-back () >> "Go back in the history to the last node visited." >> --- 2246,2255 ---- >> nil t)) >> (progn (beginning-of-line) (if (looking-at "^\\* ") (forward-char 2))) >> (goto-char p) >> ! (Info-restore-point Info-history)))) >> ! ;; If scroll-conservatively is non-zero, display as much of the >> ! ;; superior node above the target line as possible (bug#13690). >> ! (recenter)) > > I don't mind, but let's hear from others. In any case, I think this > re-centering should be conditioned on: > > . scroll-conservatively being less than 100 (people who set it to > large values don't want Emacs to recenter, ever) This is a good condition, since it effectively does the job of an option to trigger recentering (but according to the doc string, the condition should be less than 101). That way both those who never want recentering, even with Info-up, and those who do are served. Thanks for the suggestion. > . 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. > . 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? If not, then perhaps the following patch will make everyone happy. 2013-02-13 Stephen Berman * info.el (Info-up): If scroll-conservatively is less than 101, display as much of the superior node above the target line as possible. (Bug#13690)