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

[Stephen Berman <stephen.berman@gmx.net>]

[-- Attachment #1: Type: text/plain, Size: 4541 bytes --]

On Wed, 13 Feb 2013 06:02:34 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: 13690@debbugs.gnu.org
>> Date: Tue, 12 Feb 2013 23:00:56 +0100
>> 
>> >   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.        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >   ^^^^^^^^^^^^^^^^^^^^^
>> >
>> > And this is what happens in the use case you describe.  So I'm unsure
>> > why you regard this a bug.  What did you expect instead, and why?
>> 
>> I expected to see the whole node, or at least as much as possible while
>> keeping the target line in view.  I expect this because to all
>> appearances Info-up, like the other Info node navigation commands, is a
>> jumping (or zapping, warping, i.e. movement in one fell swoop), not a
>> scrolling, operation.
>
> 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.

>                         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?  Even Juanma Barranquero, who in that thread
said: "I would prefer for Emacs *never* recenter unless I ask it
explicitly via C-l," subsequently added: "No, of course I don't mind M-g
M-g recentering. I only object to recentering during scrolling (be
line-by-line or page-by-page)."  If he's reading this, I'm curious if he
is in favor of scroll-conservatively influencing Info-up, as it does
now, or would prefer (or at least accept) recentering.

>> I see that scroll_conservatively is only used in redisplay_window.
>> Does calling Fnarrow_to_region entail calling redisplay_window?
>
> redisplay_window is the workhorse of the display engine in GUI
> sessions.  It is called for _any_ kind of redisplay of any window.
>
> Narrowing only requires redisplay if it affects the portion of the
> buffer shown in the window.

This is certainly the case with Info-up (and also with my code).  Since
this doesn't involve scrolling conceptually (as opposed to its
implementation), this strengthens the case for clarifying the
documentation, at least.

>> > In general, setting scroll-conservatively to 1 tells Emacs that you
>> > are prepared to see as little as 1 line of context.
>> 
>> 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.

>> Anyway, if you (and the other Emacs maintainers) agree with my
>> arguments, would it be acceptable to add a call to recenter at the end
>> of Info-up?
>
> I don't mind.  But if you want that, why do you set
> scroll-conservatively to a non-nil value at all?

Again, I had no idea, and certainly no expectation, that setting
scroll-conservatively would affect Info-up.  I set scroll-conservatively
to 1 so that when point is at the top of the window and I type C-p, or
point is at the bottom of the window and I type C-n, then the text
scrolls by just one line.

If you and the other maintainers don't mind, I'd suggest installing the
following patch.  If anyone screams bloody murder, I can make
recentering an option.

Steve Berman


2013-02-13  Stephen Berman  <stephen.berman@gmx.net>

	* info.el (Info-up): Even if scroll-conservatively is non-zero,
	display as much of the superior node above the target line as
	possible.  (Bug#13690)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Info-up patch --]
[-- Type: text/x-patch, Size: 793 bytes --]

=== modified file 'lisp/info.el'
*** 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))
  
  (defun Info-history-back ()
    "Go back in the history to the last node visited."