From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Unfreezing the display during auto-repeated scrolling. Date: Mon, 27 Oct 2014 18:48:10 +0200 Message-ID: <83zjch31dh.fsf@gnu.org> References: <83zjcpa11g.fsf@gnu.org> <20141021171403.GB3035@acm.acm> <83oat59ucc.fsf@gnu.org> <20141021183807.GD3035@acm.acm> <20141026124333.GA4397@acm.acm> <83h9yq4w5g.fsf@gnu.org> <20141026200313.GE4397@acm.acm> <20141026221530.GF4397@acm.acm> <8361f6420v.fsf@gnu.org> <20141027100526.GB2771@acm.acm> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1414428531 17836 80.91.229.3 (27 Oct 2014 16:48:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Oct 2014 16:48:51 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 27 17:48:45 2014 Return-path: Envelope-to: ged-emacs-devel@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 1XinTJ-0004yr-8X for ged-emacs-devel@m.gmane.org; Mon, 27 Oct 2014 17:48:45 +0100 Original-Received: from localhost ([::1]:34897 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XinTI-0000Pr-TU for ged-emacs-devel@m.gmane.org; Mon, 27 Oct 2014 12:48:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47690) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XinT0-0000O9-4G for emacs-devel@gnu.org; Mon, 27 Oct 2014 12:48:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XinSv-0002mJ-DO for emacs-devel@gnu.org; Mon, 27 Oct 2014 12:48:26 -0400 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:34985) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XinSv-0002mA-15 for emacs-devel@gnu.org; Mon, 27 Oct 2014 12:48:21 -0400 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NE400J003E2EI00@mtaout25.012.net.il> for emacs-devel@gnu.org; Mon, 27 Oct 2014 18:43:44 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NE400BVI3SVBW90@mtaout25.012.net.il>; Mon, 27 Oct 2014 18:43:44 +0200 (IST) In-reply-to: <20141027100526.GB2771@acm.acm> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:175895 Archived-At: > Date: Mon, 27 Oct 2014 10:05:26 +0000 > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > From: Alan Mackenzie > > > Since you don't really care about accuracy here, .... > > That was an uncalled for gibe. It wasn't supposed to be a gibe, sorry if my wording somehow implied that. I really understood from what you wrote that you are willing to sacrifice display accuracy in order to have speedier PgDown/PgUp when leaning on the key. > I care a great deal about accuracy here. Perhaps we understand > different things by "accuracy". Perhaps. Do you at least agree that when font-lock faces change the font, not just colors, your changes will cause scrolling to sometimes land on a line other than what would happen without your changes? That's what I meant by "accuracy". > > .... you could simply move in physical lines. That's fast and doesn't > > need any support from the display engine. > > This would end up in the wrong place if there were as much as a single > continued line in the window. The same will happen with your changes, in some situations. > And one needs to know how many lines fit in the window. That's easy: take the window pixel size and divide by the default font's height. > When a user types a single PageDown/PageUp, it MUST scroll reliably > to the right place. So we can have a variant of scroll-up/down that behaves like today on the first invocation, and thereafter switches to moving point instead. Would that do what you want? > That involves knowing where continuation lines are, possibly where > invisible characters are. And one must take account of > next-screen-context-lines, and the like. Yes, and the gazillion other scroll-* options. Did you already try your changes with them? Do you always succeed to scroll as little as possible under scroll-conservatively, for example? > One might argue for using different functions for, on the one hand, single > scroll operations and scrolling over already fontified text, and on the > other hand auto-repeated ones over non-fontified text, where the accuracy > matters much less, but that's anything but simple, and would require > hairy stuff somewhere. ??? What hairy stuff? We have simple and easy-to-use mechanisms to provide commands that change their behavior when invoked repeatedly. For example, next-line does that. > If I understand correctly, your notion of accuracy in scrolling > absolutely requires that all text scrolled over must be fully fontified. The display engine must somehow know the exact same metrics of each screen line as the line will have when actually displayed. The only way we know how to do that is by "simulating display", which includes fontification, yes. > I don't see that this makes any sense at all on ttys I think we use the same code on TTYs for the simple reason not to introduce yet another separate branch in the code, which will then have separate bugs etc. > and in the very common case that all characters are equally big on a > GUI. This is IMO anti-thesis of the current GUI display engine. It was _created_ to free us from this assumption, which was considered outdated 15 years ago. It makes very little sense to me to go back to this assumption nowadays. And if you don't assume that, the hard problem is to _know_ when this is the case. We have no way of knowing that, except by scanning the buffer. > Why are you so opposed to such an optimisation? Because I spent the last few years making the display engine as accurate as possible, sometimes to (IMO) ridiculous levels, all because users complained and demanded that, not because I invented this attitude. I have a very bad feeling about this change, given that experience. > You have asserted that my patch would lead to inaccurate scrolling. Can > you give a concrete example of that happening? Just define several font-lock faces to use larger or smaller fonts, and see if you succeed to keep the promises of the various scroll-* options, like scroll-margin, scroll-step, scroll-up/down-aggressively etc. > I think I misunderstood things last night. The display engine actually > requires ALL text to be fontified when moving over it, doesn't it? See above: it needs the metrics. What parts of the text it needs the metrics of, depends on the algorithm it uses to make its decisions, in this case, where to set window-start for the next redisplay, and also whether to move point back into the view. In the case of scrolling commands, I believe that yes, it does traverse all that text. But that is not carved in stone; if someone comes with an alternative algorithm that needs to examine smaller portions of text, we can implement scrolling that is less expensive. > > There already is such a parameter, you just need to use it. > > fontification-functions is called with just one parameter, the buffer > position. Where is this other size parameter? It's the value of jit-lock-chunk-size. > > > One might argue that CC Mode fontification should be speeded up. Yes, it > > > should, but it's not ever going to be speeded up by an order of > > > magnitude. > > > I don't see why not. We could rewrite that stuff in C. > > Patches welcome. ;-) Not from me, sorry. I don't know enough about the underlying syntax infrastructure, and don't have enough motivation to learn that. And you still didn't reply to my suggestion to use jit-lock-defer-time. In my testing, setting it to 0.05 sec is enough to give you what you want, for free. That is just another evidence that we already have enough knobs in our arsenal to solve these problems when they annoy someone. E.g., I always have jit-lock-stealth turned on, so my buffers are always fully fontified, except in the few first moments of a session (something that happens rather rarely). This allows me to avoid the problem entirely, without sacrificing accuracy.