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#12811: 24.3.50; `scroll-up/down-aggressively' don't seem to work as expected Date: Wed, 07 Nov 2012 18:59:21 +0200 Message-ID: <83r4o51h92.fsf@gnu.org> References: <83ip9i3c59.fsf@gnu.org> <831ug62z3c.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1352307654 14433 80.91.229.3 (7 Nov 2012 17:00:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 7 Nov 2012 17:00:54 +0000 (UTC) Cc: 12811@debbugs.gnu.org To: Dani Moncayo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Nov 07 18:01:03 2012 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 1TW8zt-0008Ak-6j for geb-bug-gnu-emacs@m.gmane.org; Wed, 07 Nov 2012 18:01:01 +0100 Original-Received: from localhost ([::1]:51164 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TW8zj-0001Yh-UX for geb-bug-gnu-emacs@m.gmane.org; Wed, 07 Nov 2012 12:00:51 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:53734) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TW8zS-0000t3-Jz for bug-gnu-emacs@gnu.org; Wed, 07 Nov 2012 12:00:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TW8z4-00078k-GB for bug-gnu-emacs@gnu.org; Wed, 07 Nov 2012 12:00:29 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44416) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TW8z4-000750-CM for bug-gnu-emacs@gnu.org; Wed, 07 Nov 2012 12:00:10 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TW8yw-0005z6-Lm for bug-gnu-emacs@gnu.org; Wed, 07 Nov 2012 12:00:02 -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, 07 Nov 2012 17:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12811 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12811-submit@debbugs.gnu.org id=B12811.135230759622970 (code B ref 12811); Wed, 07 Nov 2012 17:00:02 +0000 Original-Received: (at 12811) by debbugs.gnu.org; 7 Nov 2012 16:59:56 +0000 Original-Received: from localhost ([127.0.0.1]:54667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TW8yq-0005yR-AG for submit@debbugs.gnu.org; Wed, 07 Nov 2012 11:59:56 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:33946) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TW8yn-0005yJ-Sl for 12811@debbugs.gnu.org; Wed, 07 Nov 2012 11:59:55 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MD400E00MPU4500@a-mtaout20.012.net.il> for 12811@debbugs.gnu.org; Wed, 07 Nov 2012 18:59:25 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MD400DT3N6XGW11@a-mtaout20.012.net.il>; Wed, 07 Nov 2012 18:59:21 +0200 (IST) In-reply-to: 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:66585 Archived-At: > Date: Wed, 7 Nov 2012 10:23:52 +0100 > From: Dani Moncayo > Cc: 12811@debbugs.gnu.org > > >> So I'd like to make this request: > >> * Make obsolete the variables `scroll-up/down-aggressively'. > >> * Extend the semantics of the variable `scroll-step' to accept also a > >> fractional number between 0 and 1, so that for example 0.7 would mean: > >> "when point moves out, try to get it back into view by scrolling > >> up/down an amount equal to the 70% of the height of the window. If > >> that fails, center in the window the line where point is". > > > > Wouldn't this keep the same semantics, but in one variable instead of > > 3? > > Not exactly: The functionality behind `scroll-up/down-aggressively' > (as explained in the manual) make no sense in some cases (after doing > a "big jump"), and is similar in spirit to the functionality behind > `scroll-step' in the other cases (after doing a "small jump"). Sorry, I see no difference. > > Anyway, it's too late to make such changes now, because a year and a > > half so ago, there a was similar discussion about > > scroll-conservatively, and people who set it to a large value > > explicitly asked for that to work over large scrolls. So the code was > > restructured to support that (that's why it was so easy for me to fix > > this one); > > I'm sorry, I fail to see how that is related to the issue at hand. :( The code which implements these variables is the same code, it just uses 3 different ways of computing where to put the window-start point so that point winds up at the desired position within the window. Once window-start was computed, the rest of the code is the same. > > going back means a serious surgery on that code, which I > > think is unjustified at this point, as I didn't hear any complaints > > about scrolling for a long time. > > But I don't think my proposal would mean "going back" It is going back because we had many complaints before to prevent centering point, when any of these variables were customized. Most complaints came from those who customize scroll-conservatively, but that variable's effect is very similar to scroll-up/down-aggressively, just expressed in other units. > as I say, in many real-life cases (e.g. when doing Isearch) the > assumption is false, and so the resulting behavior is undesirable. Why is it undesirable? > >> Good, thanks. Then perhaps the documentation should be updated to > >> reflect this, no? > > > > What's wrong with the documentation now? The code does what it says, > > no? > > Sorry I didn't get you right: I thought your change was about avoiding > that after a big jump the current line will be always centered. No, the change made the code behave as documented, no matter how far Emacs auto-scrolls.