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

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

[Stephen Berman]

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.


In GNU Emacs 24.3.50.7 (x86_64-suse-linux-gnu, GTK+ Version 3.4.4)
 of 2013-02-11 on rosalinde
Bzr revision: 111738 eggert@cs.ucla.edu-20130211194204-wj2qoqst9qvz53as
Windowing system distributor `The X.Org Foundation', version 11.0.11203000
System Description:	openSUSE 12.2 (x86_64)

Configured using:
 `configure --without-toolkit-scroll-bars CFLAGS=-g3 -O0'

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

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

[Eli Zaretskii]

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

In general, setting scroll-conservatively to 1 tells Emacs that you
are prepared to see as little as 1 line of context.

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

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

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

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

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

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

[Stephen Berman]

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

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

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

[Dmitry Gutov]

Hi Eli,

Eli Zaretskii <eliz@gnu.org> writes:
>> >                         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.

If I'm reading this right, the thread from 2010-06 has 8 messages and 5
participants. There is no way it can be representative of Emacs users in
general.

>  . Since those changes were made, 2.5 years ago, I heard _zero_
>    complaints about this behavior; you are the first one.  By

I don't think that's true anymore. You should at least remember the bug
I posted relatively recently:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13133

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

Like I explained in the bug above, the current behavior creates problems
in edge cases. So a users can choose the values that "work almost right,
but not exactly". Naturally, many people might be okay with that.

--Dmitry

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

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Cc: Stephen Berman <stephen.berman@gmx.net>,  13690@debbugs.gnu.org
> Date: Wed, 13 Feb 2013 23:02:13 +0400
> 
> >  . Since those changes were made, 2.5 years ago, I heard _zero_
> >    complaints about this behavior; you are the first one.  By
> 
> I don't think that's true anymore. You should at least remember the bug
> I posted relatively recently:
> 
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13133

OK, so he is the 2nd one since June 2010.  How does that change the
picture?

> Like I explained in the bug above, the current behavior creates problems
> in edge cases. So a users can choose the values that "work almost right,
> but not exactly".

Every behavior can be problematic in some edge cases.

Anyway, I'm not part to this argument.  I don't customize
scroll-conservatively (or any other of the scroll-* options).  I just
coded it like users who complained wanted.  Judging by the silence
since then, I'd say the change was mostly right.  But if I'm wrong,
someone else can come up and code something different.

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

[Stephen Berman]

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

On Wed, 13 Feb 2013 19:41:13 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

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

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  <stephen.berman@gmx.net>

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


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

=== modified file 'lisp/info.el'
*** lisp/info.el	2013-02-01 16:46:46 +0000
--- lisp/info.el	2013-02-13 23:13:49 +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,2256 ----
  		nil t))
  	  (progn (beginning-of-line) (if (looking-at "^\\* ") (forward-char 2)))
  	(goto-char p)
! 	(Info-restore-point Info-history))))
!   ;; If scroll-conservatively is less than 101, display as much of the
!   ;; superior node above the target line as possible (bug#13690).
!   (when (< scroll-conservatively 101)
!     (recenter)))
  
  (defun Info-history-back ()
    "Go back in the history to the last node visited."

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

[Dmitry Gutov]

On 14.02.2013 1:48, Eli Zaretskii wrote:
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Cc: Stephen Berman <stephen.berman@gmx.net>,  13690@debbugs.gnu.org
>> Date: Wed, 13 Feb 2013 23:02:13 +0400
>>
>>>   . Since those changes were made, 2.5 years ago, I heard _zero_
>>>     complaints about this behavior; you are the first one.  By
>>
>> I don't think that's true anymore. You should at least remember the bug
>> I posted relatively recently:
>>
>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13133
>
> OK, so he is the 2nd one since June 2010.  How does that change the
> picture?

Somewhat. It drastically lowers the odds of each of us being random 
crackpots. Validates the point of view, or whatever.

And since 5 is on the same order of magnitude as 2, the new opinion is 
statistically relevant.

>> Like I explained in the bug above, the current behavior creates problems
>> in edge cases. So a users can choose the values that "work almost right,
>> but not exactly".
>
> Every behavior can be problematic in some edge cases.
>
> Anyway, I'm not part to this argument.  I don't customize
> scroll-conservatively (or any other of the scroll-* options).  I just
> coded it like users who complained wanted.  Judging by the silence
> since then, I'd say the change was mostly right.  But if I'm wrong,
> someone else can come up and code something different.

I can understand if you don't want to work on it anymore.

If the stance on the issue has changed from "nobody wants that" to 
"patches welcome", I'm good, for now.

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

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

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

[Eli Zaretskii]

> Date: Thu, 14 Feb 2013 05:51:25 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: stephen.berman@gmx.net, 13690@debbugs.gnu.org
> 
> >> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13133
> >
> > OK, so he is the 2nd one since June 2010.  How does that change the
> > picture?
> 
> Somewhat. It drastically lowers the odds of each of us being random 
> crackpots.

I never said any of you were random crackpots.  I'm saying that my
interpretation of the general lack of complaints is that the behavior
is fine with most users.

> If the stance on the issue has changed from "nobody wants that" to 
> "patches welcome", I'm good, for now.

It's "nobody wants that" _and_ "patches welcome if they introduce
optional behavior".

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

[Stephen Berman]

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

On Thu, 14 Feb 2013 07:12:38 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

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

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


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

=== modified file 'lisp/info.el'
*** lisp/info.el	2013-02-14 09:15:55 +0000
--- lisp/info.el	2013-02-14 11:27:50 +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,2257 ----
  		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-zerop and less than 101, display
!   ;; as much of the superior node above the target line as possible
!   ;; (bug#13690).
!   (when (and (> scroll-conservatively 0) (< scroll-conservatively 101))
!     (recenter)))
  
  (defun Info-history-back ()
    "Go back in the history to the last node visited."

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

[Lars Ingebrigtsen]

Stephen Berman <stephen.berman@gmx.net> writes:

> 2014-02-13  Stephen Berman  <stephen.berman@gmx.net>
>
> 	* 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)

I think that makes sense to me, even if I don't use
scroll-conservatively myself, and Eli seemed to indicate that he was OK
with it, so I've now pushed your patch to Emacs 28.

If anybody objects, feel free to revert.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Stephen Berman]

On Tue, 25 Aug 2020 13:31:57 +0200 Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> 2014-02-13  Stephen Berman  <stephen.berman@gmx.net>
>>
>> 	* 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)
>
> I think that makes sense to me, even if I don't use
> scroll-conservatively myself, and Eli seemed to indicate that he was OK
> with it, so I've now pushed your patch to Emacs 28.

Thanks (also for the more idiomatic formulation).

Steve Berman