From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: E Sabof Newsgroups: gmane.emacs.bugs Subject: bug#18923: Alternative scrolling model Date: Sun, 02 Nov 2014 18:25:28 +0000 Message-ID: <87oaspa293.fsf@gmail.com> References: <87wq7e9zcn.fsf@gmail.com> <87vbmy9wdx.fsf@gmail.com> <87tx2i9vun.fsf@gmail.com> <838ujty6ns.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1414952788 4888 80.91.229.3 (2 Nov 2014 18:26:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 2 Nov 2014 18:26:28 +0000 (UTC) Cc: 18923@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 02 19:26: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 1Xkzr2-0003lc-Gg for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Nov 2014 19:26:20 +0100 Original-Received: from localhost ([::1]:58861 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xkzr2-0007Lf-3t for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Nov 2014 13:26:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46149) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xkzqu-0007LX-6F for bug-gnu-emacs@gnu.org; Sun, 02 Nov 2014 13:26:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xkzqk-0001f2-7v for bug-gnu-emacs@gnu.org; Sun, 02 Nov 2014 13:26:12 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49143) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xkzqk-0001ex-5e for bug-gnu-emacs@gnu.org; Sun, 02 Nov 2014 13:26:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Xkzqj-0002f2-Oi for bug-gnu-emacs@gnu.org; Sun, 02 Nov 2014 13:26:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: E Sabof Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 02 Nov 2014 18:26:01 +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.141495274210202 (code B ref 18923); Sun, 02 Nov 2014 18:26:01 +0000 Original-Received: (at 18923) by debbugs.gnu.org; 2 Nov 2014 18:25:42 +0000 Original-Received: from localhost ([127.0.0.1]:46356 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XkzqO-0002eS-Rb for submit@debbugs.gnu.org; Sun, 02 Nov 2014 13:25:41 -0500 Original-Received: from mail-wi0-f179.google.com ([209.85.212.179]:42264) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XkzqK-0002eB-EZ for 18923@debbugs.gnu.org; Sun, 02 Nov 2014 13:25:37 -0500 Original-Received: by mail-wi0-f179.google.com with SMTP id h11so4765838wiw.0 for <18923@debbugs.gnu.org>; Sun, 02 Nov 2014 10:25:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:to:cc:subject:in-reply-to:date:message-id :mime-version:content-type; bh=O3AK/30TnU0ciJn3ECurNGEK21ZOZ+gCUJjMDwPdLm4=; b=O4cBtdsFrkfUS1PFb0jRit+rY1ABTKa0uTR4o7e34YTMXMdpMAvA5E3BMjY2uqM00p P75lAgMiRgDXcQEhjUp8HmnGL708Iq1qfS1qYmSKdRb2hIuZ3OSi5Y51KxOzgnUR9xn6 bHsYOpKGzJ0uCxr88SNVvVBO7TYOjC1i5HIlDnzOH1NVYiP7PvDXu5VaRBtdkyu+CArR jqzAzX/2FZeqJxRzvnuLmr7/jQJdWMaa+DCdpwf2DiDMoL0hAGYb5k+czQaAy4d92z+9 HmqKgnW/RX7K//5A4qO/6zoXWohMLFf80DCdhI4qemkbJDNAZYTC6hmcecwlYzLf6tkF qlpA== X-Received: by 10.194.110.4 with SMTP id hw4mr4050841wjb.102.1414952730707; Sun, 02 Nov 2014 10:25:30 -0800 (PST) Original-Received: from ubuntu (173.103.115.87.dyn.plus.net. [87.115.103.173]) by mx.google.com with ESMTPSA id fr6sm6046021wic.1.2014.11.02.10.25.28 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 02 Nov 2014 10:25:30 -0800 (PST) In-reply-to: <838ujty6ns.fsf@gnu.org> 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:95393 Eli Zaretskii writes: >> 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 Easy to implement naively, and heuristics should probably be considered. > . the auto-window-vscroll variable I think the variable would no longer be useful with this approach. > . the scroll-preserve-screen-position option Ideally I'd measure the pixel distance from the top and try to restore it, but alternatives can be considered if this affects performance. > . signal an error at beginning and end of buffer, subject to the > value of scroll-error-top-bottom I think I already have the code that determines this case, I just need to throw errors. > . don't let point enter the scroll margin as result of scrolling > > . the window's old_point marker needs to be set after scrolling I don't fully understand these, but they don't seem too complicated. > 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. I've noticed this. The point flashes at a wrong position, and then goes back to "legal" position. I thought this was a display engine bug. >> 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.) I'm aware of some inefficiencies in my code. My guess probably doesn't mean much, but maybe something along 2X could be achieved. > 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. st-move probably shouldn't call (redisplay) at all. I'll see if I can convert my comments to reproducible bugs. >> 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? I think there are ~3 different bugs involved (vscroll not being displayed, vscroll being nullified, and the point-on-image cases). I'll see if I can describe them better. Evgeni