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 18:35:23 +0300 Message-ID: <83zjcpa11g.fsf@gnu.org> References: <20141019141712.GB3197@acm.acm> <83lhoccdv7.fsf@gnu.org> <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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1413905763 18853 80.91.229.3 (21 Oct 2014 15:36:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 Oct 2014 15:36:03 +0000 (UTC) Cc: dak@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 21 17:35:56 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 1XgbTU-0006Fs-Hf for ged-emacs-devel@m.gmane.org; Tue, 21 Oct 2014 17:35:52 +0200 Original-Received: from localhost ([::1]:51460 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgbTU-0004QJ-3H for ged-emacs-devel@m.gmane.org; Tue, 21 Oct 2014 11:35:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45310) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgbTN-0004PO-JL for emacs-devel@gnu.org; Tue, 21 Oct 2014 11:35:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XgbTH-0008Gq-5R for emacs-devel@gnu.org; Tue, 21 Oct 2014 11:35:45 -0400 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:50322) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgbT9-0008DG-4y; Tue, 21 Oct 2014 11:35:31 -0400 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NDS00H00WGXJA00@mtaout28.012.net.il>; Tue, 21 Oct 2014 18:33:32 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NDS00BP3WJWIR60@mtaout28.012.net.il>; Tue, 21 Oct 2014 18:33:32 +0300 (IDT) In-reply-to: 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.184 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:175642 Archived-At: > From: Stefan Monnier > Date: Tue, 21 Oct 2014 10:01:43 -0400 > Cc: emacs-devel@gnu.org > > >> I'd posit that the absolute correctness isn't all that important after an > >> auto-repeating PageDown. > > That would mean that if you lean on PageDown, something catches your eye > > while leafing through, you stop and press PageUp a few times in order to > > locate it, it won't reappear where it caught your eye. > > Could be, but it's highly unlikely: if it caught your eye, it means that > redisplay is fast enough to keep up with scrolling, in which case > scrolling gets to use a properly fontified buffer for its calculation, > so Alan's suggestion should make no difference in that case. In any case, the way Alan suggests is not TRT, IMNSHO. We shouldn't be sacrificing display correctness for speed; AFAIR, we never did anything like that. What we did was find and implement optimizations that catered to specific use cases that were deemed important enough. I see no reason to treat this case differently. 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. 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? 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? IOW, if the measurements show that redisplay takes 10% of the time, let's not try to optimize those 10%, but instead concentrate on the 90%.