bug#13690: 24.3.50; scroll-conservatively and Info-up

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> 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.

> >                         This is by popular demand; you can find my
> > questions about this and answers by others a year or two ago in the
> > archives.  E.g., scroll-conservatively affects commands such as
> > goto-char, even if you move far away in the buffer.
> 
> Do you mean the thread starting here:
> http://lists.gnu.org/archive/html/emacs-devel/2010-06/msg01011.html and
> continued in bug#6631?

That one, but also others.  For a recent example, see
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13055 (although that is
about scroll-margin, not scroll-conservatively).

> >> But again, as a user, I'd expect this only if what I'm doing
> >> recognizably involves scrolling, which Info-up does not, from the user's
> >> point of view.
> >
> > Alas, other users' expectations are different.
> 
> I didn't see anything to that effect in the thread cited above; did I
> miss it or were such expectations expressed elsewhere?  Again, I'd be
> quite surprised if anyone really expects and prefers the current effect
> of scroll-conservatively on Info-up.

My witnesses are twofold:

 . No one spoke about this except Juanma, and no one said that
   scroll-conservatively _must_ be confined to scroll commands.

 . Since those changes were made, 2.5 years ago, I heard _zero_
   complaints about this behavior; you are the first one.  By
   contrast, before that, when Emacs would sometimes recenter even
   when scroll-conservatively was set to a huge number, there were
   quite a few complaints and bug reports about that.

(I myself don't use this option, so Emacs always re-centers for me.)

> *** 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)

  . scroll-conservatively being non-nil

  . perhaps also scroll-margin being zero, because otherwise you get
    several lines of context before point