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#18923: Alternative scrolling model Date: Sun, 02 Nov 2014 17:16:23 +0200 Message-ID: <838ujty6ns.fsf@gnu.org> References: <87wq7e9zcn.fsf@gmail.com> <87vbmy9wdx.fsf@gmail.com> <87tx2i9vun.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1414941448 30073 80.91.229.3 (2 Nov 2014 15:17:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 2 Nov 2014 15:17:28 +0000 (UTC) Cc: 18923@debbugs.gnu.org To: E Sabof Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 02 16:17:21 2014 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 1Xkwu8-0007wb-SB for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Nov 2014 16:17:21 +0100 Original-Received: from localhost ([::1]:57572 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xkwu8-0000Ed-CJ for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Nov 2014 10:17:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49058) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xkwty-0000EM-KI for bug-gnu-emacs@gnu.org; Sun, 02 Nov 2014 10:17:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xkwtr-00061d-3v for bug-gnu-emacs@gnu.org; Sun, 02 Nov 2014 10:17:10 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49035) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xkwtr-00061Z-0P for bug-gnu-emacs@gnu.org; Sun, 02 Nov 2014 10:17:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Xkwtq-00066x-Fo for bug-gnu-emacs@gnu.org; Sun, 02 Nov 2014 10:17:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 02 Nov 2014 15:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18923 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 18923-submit@debbugs.gnu.org id=B18923.141494140823464 (code B ref 18923); Sun, 02 Nov 2014 15:17:02 +0000 Original-Received: (at 18923) by debbugs.gnu.org; 2 Nov 2014 15:16:48 +0000 Original-Received: from localhost ([127.0.0.1]:46248 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xkwtb-00066O-TV for submit@debbugs.gnu.org; Sun, 02 Nov 2014 10:16:48 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:57574) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XkwtZ-000668-LA for 18923@debbugs.gnu.org; Sun, 02 Nov 2014 10:16:46 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NEF00C003P4HC00@a-mtaout22.012.net.il> for 18923@debbugs.gnu.org; Sun, 02 Nov 2014 17:16:36 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NEF00C1W3RNAJ40@a-mtaout22.012.net.il>; Sun, 02 Nov 2014 17:16:36 +0200 (IST) In-reply-to: <87tx2i9vun.fsf@gmail.com> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.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:95379 > From: E Sabof > Date: Sun, 02 Nov 2014 02:31:28 +0000 > > > Sounds nice. Do you imagine it as a replacement for the existing > > scroll-up/down functions? Or rather (at least at first) as a separate > > package? > > Also, if something's missing for st-height to get more accurate > > measurements, I suggest you make it a bug report asking for that missing > > info/feature. > > I was mostly thinking the first. If this is intended as a replacement for the existing functionality, then it needs to support all the features that the current code supports. The list of those features should include at least the following: . the argument to the commands can be nil, which means "almost the full window", where "almost full" depends on the value of next-screen-context-lines . the auto-window-vscroll variable . the scroll-preserve-screen-position option . signal an error at beginning and end of buffer, subject to the value of scroll-error-top-bottom . don't let point enter the scroll margin as result of scrolling . the window's old_point marker needs to be set after scrolling There's also a bug when scrolling near the end of buffer: the result is that the cursor us shown on a line beyond EOB, which should never happen. > The only potentially downside I can think of > is that it might be slower -- then again I'm just measuring line-heights, and > of these there is (at most) only one line that won't eventually be displayed. It is indeed much slower. I timed it on xdisp.c using Dmitry's scroll-up-benchmark function, and found this code to be 3 times slower than the current implementation. Turning off font-lock slashes about 40% of the benchmark time, so CC mode fontifications are not the main reason for the slowdown. If I compare the existing implementation with this one on xdisp.c with font-lock-mode turned off in both cases, this implementation is 16 times slower than what we have now. For the record, my timings are from an unoptimized build of a recent trunk, with your code byte-compiled. The general algorithm seems to be the same as in the current C implementation, so I doubt an ELisp implementation could match what we have in speed, let alone be faster. Now, I personally don't regard the scrolling command as something that needs to be lightning-fast (although others obviously do, see the on-going discussions on emacs-devel about that). But in this case, a single PageDown keypress takes close to a second to execute, which is slow enough to annoy. By contrast, the current implementation is almost instantaneous. (Again, this is in an unoptimized build; an optimized build should be about twice faster, but I think 0.4 sec for a single scroll might still annoy.) Finally, it looks like this code forces Emacs to display every single screen it scrolls through, even when it cannot keep up. I guess that's due to the 'redisplay' calls. This makes the situation where someone leans on the PageDown key and then releases it very unpleasant: Emacs keeps scrolling for a long time, and I didn't find a way of interrupting that. > If it were to remain mostly elisp, it would need a reliable way to measure the > height of a line (essentially a `st-height' replacement), irrespective of > whether it's displayed. Did you try to use pos-visible-in-window-p? AFAIU, it gives you what you want, including for lines that are taller than the window. > It has also proven rather difficult to set the window > start "absolutely". I've documented my findings in `st-move'. Does this happen only when point is on an image? (The comments in st-move seem to talk only about this situation.) If so, could you show a simple test case to demonstrate the problem?