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

[Stephen Berman]

On Tue, 12 Feb 2013 18:14:33 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Date: Tue, 12 Feb 2013 00:24:49 +0100
>> 
>> 0. emacs -Q
>> 1. Type `M-x customize-option RET scroll-conservatively RET', set the
>>    value to 1 and save for the current session (or just evaluate `(setq
>>    scroll-conservatively 1)'). 
>> 2. Type `C-h r m Basic RET m Repeating RET' to go to the Info node
>>    (emacs)Repeating.
>> 3. Type `u' or `^' to go up to the node (emacs)Basic, with point on the
>>    menu Entry "Repeating".
>> ==> The line point is on is at the top of the window, so all higher
>>     lines in the buffer are out of view.
>> 
>> In general, when scroll-conservatively is set to n (n > 0), then if
>> Info-up puts point on the nth line counting from eob, or on a lower line
>> (closer to eob), the start of that line is at window-start; if Info-up
>> puts point on a higher line than the nth above eob, then the whole
>> buffer is visible (up to recentering).  If scroll-conservatively has its
>> default value 0, the buffer display following Info-up is always
>> recentered.
>
> This is exactly the behavior under scroll-conservatively:
>
>   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.  And when I jump to another node I expect to see
all of it, or as much as possible.  I find support for this
interpretation from the doc string of Info-up, which says: "Go to the
superior node of this node." not: "Scroll to the superior node...".  So
I had no reason to expect, as a user, that setting scroll-conservatively
should affect Info node navigation.  And I'd be surprised if someone
deliberately uses scroll-conservatively to regulate navigation between
Info nodes, because its specific effect on a given use of Info-up
depends, as I noted above, on how many menu lines are in the parent
node, and this varies from node to node.

Moreover, looking at the the code I see no calls of scrolling functions
in Info-up or its subroutines (in particular, Info-find-node-2).  But
since narrowing is involved, I'd be interested to know if narrowing
triggers scrolling and hence the effect of scroll-conservatively.  I see
that scroll_conservatively is only used in redisplay_window.  Does
calling Fnarrow_to_region entail calling redisplay_window?  I'm
interested not just because of Info-up but also because I have code that
uses narrowing and I've observed similar effects there to the Info-up
effect I reported (though it appears that my code shows the effects even
when scroll-conservatively is set to 0, so it may not be related).

> 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.

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?  Doing that gives the display I expect when
scroll-conservatively is non-zero and makes no difference when it is
zero.  (I also call recenter to work around the similar problems in my
own code.)  And if you don't agree with my arguments, i.e. if you think
scroll-conservatively should really be able to affect Info node
navigation, would you at least consider adding an option to do
recentering?  (Of course, if the problem (as I see it) is really due to
narrowing, then it probably shows up in other packages, so a general
approach would be better, but at least this could be an interim
solution.)

Steve Berman