From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#13690: 24.3.50; scroll-conservatively and Info-up Date: Wed, 13 Feb 2013 19:41:13 +0200 Message-ID: <83mwv83ydi.fsf@gnu.org> References: <87sj52juwu.fsf@rosalinde.fritz.box> <834nhh5x1y.fsf@gnu.org> <87ip5xp4yv.fsf@rosalinde.fritz.box> <83txpg509x.fsf@gnu.org> <87621w72th.fsf@rosalinde.fritz.box> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1360777313 14912 80.91.229.3 (13 Feb 2013 17:41:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Feb 2013 17:41:53 +0000 (UTC) Cc: 13690@debbugs.gnu.org To: Stephen Berman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Feb 13 18:42:12 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 1U5gLM-00006t-4R for geb-bug-gnu-emacs@m.gmane.org; Wed, 13 Feb 2013 18:42:04 +0100 Original-Received: from localhost ([::1]:41896 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U5gL2-00082N-H6 for geb-bug-gnu-emacs@m.gmane.org; Wed, 13 Feb 2013 12:41:44 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:39097) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U5gKw-00081D-14 for bug-gnu-emacs@gnu.org; Wed, 13 Feb 2013 12:41:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U5gKn-0002AQ-SQ for bug-gnu-emacs@gnu.org; Wed, 13 Feb 2013 12:41:37 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49006) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U5gKn-0002AL-Ov for bug-gnu-emacs@gnu.org; Wed, 13 Feb 2013 12:41:29 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1U5gLJ-0005Y5-TZ for bug-gnu-emacs@gnu.org; Wed, 13 Feb 2013 12:42:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 Feb 2013 17:42: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.136077730021303 (code B ref 13690); Wed, 13 Feb 2013 17:42:01 +0000 Original-Received: (at 13690) by debbugs.gnu.org; 13 Feb 2013 17:41:40 +0000 Original-Received: from localhost ([127.0.0.1]:54470 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5gKx-0005XX-KE for submit@debbugs.gnu.org; Wed, 13 Feb 2013 12:41:40 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:40805) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5gKv-0005XP-Bl for 13690@debbugs.gnu.org; Wed, 13 Feb 2013 12:41:38 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MI6007006DLTW00@a-mtaout22.012.net.il> for 13690@debbugs.gnu.org; Wed, 13 Feb 2013 19:40:59 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MI6006306GA9AA1@a-mtaout22.012.net.il>; Wed, 13 Feb 2013 19:40:59 +0200 (IST) In-reply-to: <87621w72th.fsf@rosalinde.fritz.box> X-012-Sender: halo1@inter.net.il 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:71191 Archived-At: > From: Stephen Berman > 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