From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Aborting display. Is this possible? Date: Tue, 21 Oct 2014 12:27:51 -0400 Message-ID: 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> <83zjcpa11g.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1413908905 9645 80.91.229.3 (21 Oct 2014 16:28:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 Oct 2014 16:28:25 +0000 (UTC) Cc: dak@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 21 18:28:17 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 1XgcIC-0008GR-Eh for ged-emacs-devel@m.gmane.org; Tue, 21 Oct 2014 18:28:16 +0200 Original-Received: from localhost ([::1]:52239 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgcIC-0005qC-36 for ged-emacs-devel@m.gmane.org; Tue, 21 Oct 2014 12:28:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34894) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgcHs-0005pV-9K for emacs-devel@gnu.org; Tue, 21 Oct 2014 12:28:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XgcHk-00047J-Qw for emacs-devel@gnu.org; Tue, 21 Oct 2014 12:27:56 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:50531) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgcHk-000478-Mm; Tue, 21 Oct 2014 12:27:48 -0400 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s9LGRkgk029192; Tue, 21 Oct 2014 12:27:46 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 3EBA2660D6; Tue, 21 Oct 2014 12:27:51 -0400 (EDT) In-Reply-To: <83zjcpa11g.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 21 Oct 2014 18:35:23 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5101=0 X-NAI-Spam-Version: 2.3.0.9378 : core <5101> : inlines <1416> : streams <1322603> : uri <1827312> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:175647 Archived-At: > 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? Indeed, that'd be better. But IIUC Alan has already been working fairly hard to make CC-mode's parsing faster. So my guess is that either it's just really hard because of some details of the C language, or we'd need a serious restructuring/rewrite and I don't think anyone is up for that. > 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%. There's some general pressure to improve font-locking by making it more precise, with somewhat marginal improvements but fairly high processing costs (pushed to the extreme, this involves passing the text to an external toolchain that parses and type-checks and returns to Emacs the precise highlighting info; see for example agda-mode). So, maybe we're looking at a future where we'll need to provide some way for delayed/asynchronous font-lock refinement. Stefan