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: Aborting display. Is this possible? Date: Tue, 21 Oct 2014 21:00:03 +0300 Message-ID: <83oat59ucc.fsf@gnu.org> References: <20141019154255.GC3197@acm.acm> <83egu4c4om.fsf@gnu.org> <20141020110949.GA2947@acm.acm> <8338aidbcq.fsf@gnu.org> <20141020185757.GD2947@acm.acm> <83lhoabl2x.fsf@gnu.org> <20141020210819.GE2947@acm.acm> <87y4s9rgi9.fsf@fencepost.gnu.org> <83zjcpa11g.fsf@gnu.org> <20141021171403.GB3035@acm.acm> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1413914459 7435 80.91.229.3 (21 Oct 2014 18:00:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 Oct 2014 18:00:59 +0000 (UTC) Cc: dak@gnu.org, 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 Tue Oct 21 20:00:52 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 1Xgdjn-0003u6-I0 for ged-emacs-devel@m.gmane.org; Tue, 21 Oct 2014 20:00:51 +0200 Original-Received: from localhost ([::1]:52828 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xgdjn-0002CD-7d for ged-emacs-devel@m.gmane.org; Tue, 21 Oct 2014 14:00:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59506) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgdjJ-00029u-F4 for emacs-devel@gnu.org; Tue, 21 Oct 2014 14:00:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XgdjD-0008EY-W4 for emacs-devel@gnu.org; Tue, 21 Oct 2014 14:00:21 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:43677) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xgdj8-0008DS-OB; Tue, 21 Oct 2014 14:00:10 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NDT002002ZGPA00@a-mtaout20.012.net.il>; Tue, 21 Oct 2014 21:00:09 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NDT002BV3C8AI70@a-mtaout20.012.net.il>; Tue, 21 Oct 2014 21:00:09 +0300 (IDT) In-reply-to: <20141021171403.GB3035@acm.acm> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:175655 Archived-At: > Date: Tue, 21 Oct 2014 17:14:03 +0000 > Cc: Stefan Monnier , dak@gnu.org, > emacs-devel@gnu.org > From: Alan Mackenzie > > > Another data point is this: in the recent years, I've dealt with any > > number of bug reports that complained about minor inaccuracies in > > scrolling, mostly by fractions of line height or even by a couple of > > pixels. My interpretation of this is that our users expect accurate > > display, and will not easily tolerate sloppiness. > > This is a red herring, surely? No, it's a data point. And you already got one other opinion along these same lines. > Tiny fractions, visible, of the line height are totally orthogonal > to being one or two lines out (which won't even be visible) after a > "sloppy" user action. I ensure you they _will_ be visible. Our users are very sharp-eyed. > > So I suggest to turn the table and ask: how come fontification of C > > sources is so expensive, and how can we make it faster? > > It has got slower as it has become more accurate. Users have complained > about slight inaccuracies in fontification, too. Fast enough would mean > speeding it up by a factor of around 5. I don't think this is > practicable. Of course, it's practicable! E.g., make it by default do what CC Mode did a few years ago. There was time when I could scroll through xdisp.c on a much slower machine I have today, and Emacs would keep up, you know. Let users who want "more accurate fontification" ask for it, and pay the price! I'm not saying that's necessarily what we should do, but it surely is one way. > > If the Lisp implementation cannot be sped up significantly, let's > > implement some of the code in C. Or maybe we are should request less > > accurate parsing of the source, at least by default -- e.g., perhaps it > > is not very important to display variables in a face that is different > > from, say, data types? > > You're suggesting sacrificing fontification accuracy for scrolling > accuracy? :-) That's a possibility, yes. Fontification doesn't have to be as accurate as the compiler. > A very common use case for programming languages is when all the > font-lock-* faces are mono-spaced of equal size. This might even be the > overwhelming majority of use. Yet the scrolling/display code makes no > optimisation for this. In this very common case, it is entirely > unnecessary to fontify bits of buffer to work out how much text would fit > onto the screen we want to scroll over. We've been through that already: the problem is how does the display engine _know_ this is the case, without examining the buffer and the text properties? Suggest a reliable and easy to use mechanism for that, and you've got my vote. But assuming without any grounds that this is the situation, based on just the mode, is a non-starter. It will wreak havoc on many widely used support modes. > The whole point of Jit Lock was that we would only need to fontify the > bits of the buffer currently being displayed. This was partly so that > mode maintainers could be a bit more relaxed about the speed of > font-locking. The scenario of auto-repeat on PageDown suggests that the > mechanism wasn't fully thought out. Well, think it out better, if you can. Suggestions for algorithmic improvements of the display engine are most welcome. > I still say an optimisation to the scrolling code, where an option could > specify that all faces are of the same size (or should be deemed to be > so) is called for here. Details, please! What option, how it will be used, and how do we ensure it is not abused -- these are the first issues I'd like to hear. And I still think you are barking up the wrong tree: the CC Mode is slow, so it is the one that needs to be worked on.