From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Unfreezing the display during auto-repeated scrolling. Date: Mon, 27 Oct 2014 22:46:10 +0000 Message-ID: <20141027224610.GE2771@acm.acm> References: <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> <83zjch31dh.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1414450041 24679 80.91.229.3 (27 Oct 2014 22:47:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Oct 2014 22:47:21 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 27 23:47:14 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 1Xit4E-00078r-6C for ged-emacs-devel@m.gmane.org; Mon, 27 Oct 2014 23:47:14 +0100 Original-Received: from localhost ([::1]:36299 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xit4D-0001HW-NH for ged-emacs-devel@m.gmane.org; Mon, 27 Oct 2014 18:47:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35745) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xit3w-0001Fi-1r for emacs-devel@gnu.org; Mon, 27 Oct 2014 18:47:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xit3r-0005MV-BQ for emacs-devel@gnu.org; Mon, 27 Oct 2014 18:46:56 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:39640 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xit3r-0005MI-1r for emacs-devel@gnu.org; Mon, 27 Oct 2014 18:46:51 -0400 Original-Received: (qmail 93212 invoked by uid 3782); 27 Oct 2014 22:46:49 -0000 Original-Received: from acm.muc.de (pD951B8EC.dip0.t-ipconnect.de [217.81.184.236]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 27 Oct 2014 23:46:48 +0100 Original-Received: (qmail 25842 invoked by uid 1000); 27 Oct 2014 22:46:10 -0000 Content-Disposition: inline In-Reply-To: <83zjch31dh.fsf@gnu.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 8.x X-Received-From: 193.149.48.1 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:175911 Archived-At: Hello, Eli. A lot of your post has become overtaken by other things in the last few hours, but I'll answer anyway. On Mon, Oct 27, 2014 at 06:48:10PM +0200, Eli Zaretskii wrote: > > Date: Mon, 27 Oct 2014 10:05:26 +0000 > > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > > From: Alan Mackenzie > > 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". Yes, I do. However, I can't persuade myself that this is anything but a special case. Do people actually use mixtures of faces where the font isn't the same as the default's? What for? > > > .... 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. Admitted. > > 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? No. Typing a sequence of deliberate scroll-ups/downs, one at a time, is a common and reasonable thing to do, so they should work properly. Only when the scroll-ups/downs start coming in faster than human typing rate should we switch to the point moving command. > > 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? Yes, they seem fine. (That's with the binding-fontification-functions-to-nil patch.) > > 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. Having variable size fonts is great (possibly essential) for Emacs, but they create an overhead, and that overhead is imposed on users with no need for the feature. It's analogous to font lock - a programmer's editor without font locking is almost inconceivable today (unlike 20 years ago), but for those who don't want it, we don't impose the processing overhead on them when they disable it. > 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. Allowing the user to decide by setting an option, a bit like we allow her to turn font-lock mode off. > 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. If Stefan's suggestion to modify jit-lock-defer so that it only kicks in when the event-queue is non-empty works, you could be right. > 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. I have default jit-lock settings, and power up my machine sometimes several times a day. I think customising jit-lock is just too difficult for most users. (I find it difficult enough that I don't bother.) -- Alan Mackenzie (Nuremberg, Germany).