From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.bugs Subject: bug#13690: 24.3.50; scroll-conservatively and Info-up Date: Tue, 12 Feb 2013 23:00:56 +0100 Message-ID: <87ip5xp4yv.fsf@rosalinde.fritz.box> References: <87sj52juwu.fsf@rosalinde.fritz.box> <834nhh5x1y.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1360708563 18666 80.91.229.3 (12 Feb 2013 22:36:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 12 Feb 2013 22:36:03 +0000 (UTC) Cc: 13690@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Feb 12 23:36:24 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U5OSd-0006Ow-Lr for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Feb 2013 23:36:23 +0100 Original-Received: from localhost ([::1]:33273 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U5OSK-0007O3-16 for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Feb 2013 17:36:04 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:36384) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U5Nv0-0000XY-9x for bug-gnu-emacs@gnu.org; Tue, 12 Feb 2013 17:01:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U5Nuw-0001NQ-Nc for bug-gnu-emacs@gnu.org; Tue, 12 Feb 2013 17:01:38 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:47219) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U5Nuw-0001NM-Ke for bug-gnu-emacs@gnu.org; Tue, 12 Feb 2013 17:01:34 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1U5NvO-00010e-25 for bug-gnu-emacs@gnu.org; Tue, 12 Feb 2013 17:02:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stephen Berman Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Feb 2013 22:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13690 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 13690-submit@debbugs.gnu.org id=B13690.13607064953773 (code B ref 13690); Tue, 12 Feb 2013 22:02:01 +0000 Original-Received: (at 13690) by debbugs.gnu.org; 12 Feb 2013 22:01:35 +0000 Original-Received: from localhost ([127.0.0.1]:52683 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5Nuv-0000yg-8v for submit@debbugs.gnu.org; Tue, 12 Feb 2013 17:01:33 -0500 Original-Received: from mout.gmx.net ([212.227.17.20]:62213) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5Nur-0000yD-E0 for 13690@debbugs.gnu.org; Tue, 12 Feb 2013 17:01:31 -0500 Original-Received: from mailout-de.gmx.net ([10.1.76.19]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LrXxT-1V42yn0WxZ-013MSg for <13690@debbugs.gnu.org>; Tue, 12 Feb 2013 23:01:00 +0100 Original-Received: (qmail invoked by alias); 12 Feb 2013 22:00:59 -0000 Original-Received: from i59F5479C.versanet.de (EHLO rosalinde.fritz.box) [89.245.71.156] by mail.gmx.net (mp019) with SMTP; 12 Feb 2013 23:00:59 +0100 X-Authenticated: #20778731 X-Provags-ID: V01U2FsdGVkX19fE9smdqBfu4XsI4Y2aercD6zzPbvvK2njOyJcHU 8Bd0iRjSRNQbKU In-Reply-To: <834nhh5x1y.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 12 Feb 2013 18:14:33 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-Y-GMX-Trusted: 0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:71123 Archived-At: On Tue, 12 Feb 2013 18:14:33 +0200 Eli Zaretskii wrote: >> From: Stephen Berman >> 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