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: Wed, 13 Feb 2013 14:36:58 +0100 Message-ID: <87621w72th.fsf@rosalinde.fritz.box> References: <87sj52juwu.fsf@rosalinde.fritz.box> <834nhh5x1y.fsf@gnu.org> <87ip5xp4yv.fsf@rosalinde.fritz.box> <83txpg509x.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: ger.gmane.org 1360762687 21906 80.91.229.3 (13 Feb 2013 13:38:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Feb 2013 13:38:07 +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 Wed Feb 13 14:38:28 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 1U5cXU-0001IZ-Lv for geb-bug-gnu-emacs@m.gmane.org; Wed, 13 Feb 2013 14:38:20 +0100 Original-Received: from localhost ([::1]:45098 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U5cX8-0005d1-TL for geb-bug-gnu-emacs@m.gmane.org; Wed, 13 Feb 2013 08:37:58 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:55707) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U5cX3-0005cj-Qc for bug-gnu-emacs@gnu.org; Wed, 13 Feb 2013 08:37:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U5cWz-0006ao-JI for bug-gnu-emacs@gnu.org; Wed, 13 Feb 2013 08:37:53 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:47992) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U5cWz-0006ag-Fx for bug-gnu-emacs@gnu.org; Wed, 13 Feb 2013 08:37:49 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1U5cXK-0008Hx-6m for bug-gnu-emacs@gnu.org; Wed, 13 Feb 2013 08:38:14 -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: Wed, 13 Feb 2013 13:38:09 +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.136076265831808 (code B ref 13690); Wed, 13 Feb 2013 13:38:09 +0000 Original-Received: (at 13690) by debbugs.gnu.org; 13 Feb 2013 13:37:38 +0000 Original-Received: from localhost ([127.0.0.1]:53456 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5cWm-0008Gh-Uc for submit@debbugs.gnu.org; Wed, 13 Feb 2013 08:37:37 -0500 Original-Received: from mout.gmx.net ([212.227.15.19]:65385) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5cWk-0008Fk-0l for 13690@debbugs.gnu.org; Wed, 13 Feb 2013 08:37:35 -0500 Original-Received: from mailout-de.gmx.net ([10.1.76.28]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MHuiJ-1U4FbU1kUP-003dnx for <13690@debbugs.gnu.org>; Wed, 13 Feb 2013 14:37:01 +0100 Original-Received: (qmail invoked by alias); 13 Feb 2013 13:37:00 -0000 Original-Received: from i59F54952.versanet.de (EHLO rosalinde.fritz.box) [89.245.73.82] by mail.gmx.net (mp028) with SMTP; 13 Feb 2013 14:37:00 +0100 X-Authenticated: #20778731 X-Provags-ID: V01U2FsdGVkX19y44E6C/hy+w8wq5Ieix4QABDyxsxFYKbyg8Ir27 wiIGzHfeB+fE6I In-Reply-To: <83txpg509x.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 13 Feb 2013 06:02:34 +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:71172 Archived-At: --=-=-= Content-Type: text/plain On Wed, 13 Feb 2013 06:02:34 +0200 Eli Zaretskii wrote: >> From: Stephen Berman >> 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 * 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) --=-=-= Content-Type: text/x-patch Content-Disposition: inline Content-Description: Info-up patch === 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." --=-=-=--