From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: cc-mode fontification feels random Date: Sat, 12 Jun 2021 09:31:46 +0000 Message-ID: References: <83fsxpbpn9.fsf@gnu.org> <83k0n09tkp.fsf@gnu.org> <837dj09p0e.fsf@gnu.org> <83wnqz8tuq.fsf@gnu.org> <179ff3c71f0.2816.cc5b3318d7e9908e2c46732289705cb0@dancol.org> <83o8cb8pz5.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36339"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rudalics@gmx.at, Daniel Colascione , emacs-devel@gnu.org, monnier@iro.umontreal.ca, rms@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 12 11:32:29 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ls00D-0009Ho-Ou for ged-emacs-devel@m.gmane-mx.org; Sat, 12 Jun 2021 11:32:29 +0200 Original-Received: from localhost ([::1]:45888 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ls00C-0004lH-8F for ged-emacs-devel@m.gmane-mx.org; Sat, 12 Jun 2021 05:32:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59696) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lrzzc-00046C-7h for emacs-devel@gnu.org; Sat, 12 Jun 2021 05:31:52 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:35684 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1lrzzZ-0005cX-To for emacs-devel@gnu.org; Sat, 12 Jun 2021 05:31:52 -0400 Original-Received: (qmail 83938 invoked by uid 3782); 12 Jun 2021 09:31:47 -0000 Original-Received: from acm.muc.de (p2e5d50e5.dip0.t-ipconnect.de [46.93.80.229]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 12 Jun 2021 11:31:47 +0200 Original-Received: (qmail 4086 invoked by uid 1000); 12 Jun 2021 09:31:46 -0000 Content-Disposition: inline In-Reply-To: <83o8cb8pz5.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:270750 Archived-At: Hello, Eli. On Sat, Jun 12, 2021 at 11:08:30 +0300, Eli Zaretskii wrote: > > From: Daniel Colascione > > CC: , , , > > Date: Sat, 12 Jun 2021 01:00:22 -0700 > > > It is a problem given how much the current fast machines can do during > > > that time. At 3 GHz, 30 msec of CPU time is equivalent to 100 million > > > machine instructions. > > And if you count electrons, the numbers are in the trillions. So what? Who > > cares how many machine instructions it is? What matters is the latency. > I'm saying that, given how much these machines can do in 30 msec, it > doesn't sound right that we cannot refontify 35 lines of text with all > that processing power. It tells me that our code is either very > inefficient or does a lot of unnecessary processing (or both). Or, due to the quirks of the CC Mode languages, it simply needs that much processing to do an accurate job (or all three). > Alan thought that the performance we have is acceptable. The numbers > I mentioned would hopefully convince him otherwise. I think the performance is fully acceptable to a normal user on a 3.4 GHz modern machine. If the processing power is available, why not make use of it? > > > We should either find a way of making this analysis faster, or give up > > > on fontifying these two cases differently. It is IMO unacceptable > > > that redisplay is slowed down so much by mode-specific fontifications. As mentioned already, we have the facility of setting font-lock-maximum-decoration to 2, which triples fontification speed. This comes at the cost of accuracy. A lot of the bug reports I've fielded over the years have been about fontification inaccuracies. > > This is a great example of where incorrect fontification diminishes the > > utility of syntax highlighting more generally. If I can't trust the color > > of a symbol to distinguish a variable declaration from a type declaration, > > why bother fontifying as either? > I think we are saying the same, just in different words. > Do you agree that slowing down redisplay so much due to fontification > is unacceptable? I think I would answer that on a modern machine (certainly from the last 5 years), using a normally optimised Emacs build, the fontification isn't slowed down. On a somewhat slower machine, it could become unacceptable, but that there are accpetable workarounds (setting font-lock-maximum-decoration, or enabling fast-but-imprecise-scrolling, or enabling deferred fontification). On a much slower machine, the above doesn't hold, no. I can't agree that we should expect C Mode to fontify with around the same amount of processing as Emacs Lisp Mode. This isn't reasonable. -- Alan Mackenzie (Nuremberg, Germany).