* bug#13690: 24.3.50; scroll-conservatively and Info-up
@ 2013-02-11 23:24 Stephen Berman
2013-02-12 16:14 ` Eli Zaretskii
0 siblings, 1 reply; 15+ messages in thread
From: Stephen Berman @ 2013-02-11 23:24 UTC (permalink / raw)
To: 13690
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
^ permalink raw reply [flat|nested] 15+ messages in thread* bug#13690: 24.3.50; scroll-conservatively and Info-up 2013-02-11 23:24 bug#13690: 24.3.50; scroll-conservatively and Info-up Stephen Berman @ 2013-02-12 16:14 ` Eli Zaretskii 2013-02-12 22:00 ` Stephen Berman 0 siblings, 1 reply; 15+ messages in thread From: Eli Zaretskii @ 2013-02-12 16:14 UTC (permalink / raw) To: Stephen Berman; +Cc: 13690 > 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#13690: 24.3.50; scroll-conservatively and Info-up 2013-02-12 16:14 ` Eli Zaretskii @ 2013-02-12 22:00 ` Stephen Berman 2013-02-13 4:02 ` Eli Zaretskii 0 siblings, 1 reply; 15+ messages in thread From: Stephen Berman @ 2013-02-12 22:00 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13690 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#13690: 24.3.50; scroll-conservatively and Info-up 2013-02-12 22:00 ` Stephen Berman @ 2013-02-13 4:02 ` Eli Zaretskii 2013-02-13 13:36 ` Stephen Berman 0 siblings, 1 reply; 15+ messages in thread From: Eli Zaretskii @ 2013-02-13 4:02 UTC (permalink / raw) To: Stephen Berman; +Cc: 13690 > 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? ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#13690: 24.3.50; scroll-conservatively and Info-up 2013-02-13 4:02 ` Eli Zaretskii @ 2013-02-13 13:36 ` Stephen Berman 2013-02-13 17:41 ` Eli Zaretskii 0 siblings, 1 reply; 15+ messages in thread From: Stephen Berman @ 2013-02-13 13:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13690 [-- 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." ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#13690: 24.3.50; scroll-conservatively and Info-up 2013-02-13 13:36 ` Stephen Berman @ 2013-02-13 17:41 ` Eli Zaretskii 2013-02-13 19:02 ` Dmitry Gutov 2013-02-13 23:18 ` Stephen Berman 0 siblings, 2 replies; 15+ messages in thread From: Eli Zaretskii @ 2013-02-13 17:41 UTC (permalink / raw) To: Stephen Berman; +Cc: 13690 > 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#13690: 24.3.50; scroll-conservatively and Info-up 2013-02-13 17:41 ` Eli Zaretskii @ 2013-02-13 19:02 ` Dmitry Gutov 2013-02-13 21:48 ` Eli Zaretskii 2013-02-13 23:18 ` Stephen Berman 1 sibling, 1 reply; 15+ messages in thread From: Dmitry Gutov @ 2013-02-13 19:02 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Stephen Berman, 13690 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#13690: 24.3.50; scroll-conservatively and Info-up 2013-02-13 19:02 ` Dmitry Gutov @ 2013-02-13 21:48 ` Eli Zaretskii 2013-02-14 1:51 ` Dmitry Gutov 0 siblings, 1 reply; 15+ messages in thread From: Eli Zaretskii @ 2013-02-13 21:48 UTC (permalink / raw) To: Dmitry Gutov; +Cc: stephen.berman, 13690 > 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#13690: 24.3.50; scroll-conservatively and Info-up 2013-02-13 21:48 ` Eli Zaretskii @ 2013-02-14 1:51 ` Dmitry Gutov 2013-02-14 5:16 ` Eli Zaretskii 0 siblings, 1 reply; 15+ messages in thread From: Dmitry Gutov @ 2013-02-14 1:51 UTC (permalink / raw) To: Eli Zaretskii; +Cc: stephen.berman, 13690 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#13690: 24.3.50; scroll-conservatively and Info-up 2013-02-14 1:51 ` Dmitry Gutov @ 2013-02-14 5:16 ` Eli Zaretskii 0 siblings, 0 replies; 15+ messages in thread From: Eli Zaretskii @ 2013-02-14 5:16 UTC (permalink / raw) To: Dmitry Gutov; +Cc: stephen.berman, 13690 > 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". ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#13690: 24.3.50; scroll-conservatively and Info-up 2013-02-13 17:41 ` Eli Zaretskii 2013-02-13 19:02 ` Dmitry Gutov @ 2013-02-13 23:18 ` Stephen Berman 2013-02-14 5:12 ` Eli Zaretskii 1 sibling, 1 reply; 15+ messages in thread From: Stephen Berman @ 2013-02-13 23:18 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13690 [-- 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." ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#13690: 24.3.50; scroll-conservatively and Info-up 2013-02-13 23:18 ` Stephen Berman @ 2013-02-14 5:12 ` Eli Zaretskii 2013-02-14 11:32 ` Stephen Berman 0 siblings, 1 reply; 15+ messages in thread From: Eli Zaretskii @ 2013-02-14 5:12 UTC (permalink / raw) To: Stephen Berman; +Cc: 13690 > 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#13690: 24.3.50; scroll-conservatively and Info-up 2013-02-14 5:12 ` Eli Zaretskii @ 2013-02-14 11:32 ` Stephen Berman 2020-08-25 11:31 ` Lars Ingebrigtsen 0 siblings, 1 reply; 15+ messages in thread From: Stephen Berman @ 2013-02-14 11:32 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13690 [-- 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." ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#13690: 24.3.50; scroll-conservatively and Info-up 2013-02-14 11:32 ` Stephen Berman @ 2020-08-25 11:31 ` Lars Ingebrigtsen 2020-08-25 18:02 ` Stephen Berman 0 siblings, 1 reply; 15+ messages in thread From: Lars Ingebrigtsen @ 2020-08-25 11:31 UTC (permalink / raw) To: Stephen Berman; +Cc: 13690 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#13690: 24.3.50; scroll-conservatively and Info-up 2020-08-25 11:31 ` Lars Ingebrigtsen @ 2020-08-25 18:02 ` Stephen Berman 0 siblings, 0 replies; 15+ messages in thread From: Stephen Berman @ 2020-08-25 18:02 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 13690 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2020-08-25 18:02 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-02-11 23:24 bug#13690: 24.3.50; scroll-conservatively and Info-up Stephen Berman 2013-02-12 16:14 ` Eli Zaretskii 2013-02-12 22:00 ` Stephen Berman 2013-02-13 4:02 ` Eli Zaretskii 2013-02-13 13:36 ` Stephen Berman 2013-02-13 17:41 ` Eli Zaretskii 2013-02-13 19:02 ` Dmitry Gutov 2013-02-13 21:48 ` Eli Zaretskii 2013-02-14 1:51 ` Dmitry Gutov 2013-02-14 5:16 ` Eli Zaretskii 2013-02-13 23:18 ` Stephen Berman 2013-02-14 5:12 ` Eli Zaretskii 2013-02-14 11:32 ` Stephen Berman 2020-08-25 11:31 ` Lars Ingebrigtsen 2020-08-25 18:02 ` Stephen Berman
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).