From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: cc-mode fontification feels random Date: Sat, 12 Jun 2021 01:00:22 -0700 Message-ID: <179ff3c71f0.2816.cc5b3318d7e9908e2c46732289705cb0@dancol.org> References: <83k0n2cjg5.fsf@gnu.org> <83im2lbqmv.fsf@gnu.org> <179f6e4fa40.2816.cc5b3318d7e9908e2c46732289705cb0@dancol.org> <83fsxpbpn9.fsf@gnu.org> <83k0n09tkp.fsf@gnu.org> <837dj09p0e.fsf@gnu.org> <83wnqz8tuq.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15823"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: AquaMail/1.29.2-1810 (build: 102900008) Cc: rudalics@gmx.at, emacs-devel@gnu.org, monnier@iro.umontreal.ca, rms@gnu.org To: Eli Zaretskii , Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 12 10:03:30 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 1lryc5-0003xF-27 for ged-emacs-devel@m.gmane-mx.org; Sat, 12 Jun 2021 10:03:29 +0200 Original-Received: from localhost ([::1]:38770 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lryc3-0000Ty-T1 for ged-emacs-devel@m.gmane-mx.org; Sat, 12 Jun 2021 04:03:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51466) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lryZH-000886-Od for emacs-devel@gnu.org; Sat, 12 Jun 2021 04:00:35 -0400 Original-Received: from dancol.org ([2600:3c01:e000:3d8::1]:56924) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lryZF-0001k8-64; Sat, 12 Jun 2021 04:00:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=oR3czY5KWTCPuTJKciKfJwiC6T/7tAAQkrwlougnq1w=; b=D2bdtFVTH6lOaeMCLNUv6WknZA Idg8xhSji8L5/WRex+4GDVK5S7Lu5hqPWAtuKaCBEOg9qWLgAGCgAXo00imGUnErDQ16Wb6PjlZ9R S+NC08NyDu0FpLl8A1gJS3ZlNWnsEoL8o94LX8qEX75fLM2Cysz3G0boSLhuvsT3inOF/hGe8wddA NuOjHvDEbfvcmEZaJrohiVL8SCl0+SJ+2kPNAZnmYsqzm3aF1iBY2NmglNZbm7mPU697/EtA9xpZu 5z9C186lY7+WpieLR7kXddWnDSr4ifnTvhzBvffiOqol+UlRpS5I907uhsrJ+s0fD+3L+PBVo/27/ 4rO2xeYA==; Original-Received: from 112.sub-174-194-194.myvzw.com ([174.194.194.112]:4413 helo=[100.112.62.55]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.89) (envelope-from ) id 1lryZ8-0003rF-Lx; Sat, 12 Jun 2021 01:00:26 -0700 In-Reply-To: <83wnqz8tuq.fsf@gnu.org> Received-SPF: pass client-ip=2600:3c01:e000:3d8::1; envelope-from=dancol@dancol.org; helo=dancol.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-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:270744 Archived-At: On June 11, 2021 11:45:04 PM Eli Zaretskii wrote: >> Date: Fri, 11 Jun 2021 20:06:30 +0000 >> Cc: Stefan Monnier , dancol@dancol.org, >> rudalics@gmx.at, rms@gnu.org, emacs-devel@gnu.org >> From: Alan Mackenzie >> >> Why do we have a problem? If the time taken to fontify a window is less >> than the auto-repeat time (the two times are close on a modern machine), >> this is surely not a problem for somebody with such a machine. It could >> be a problem for somebody with a slower machine, or running an >> unoptimised Emacs. > > 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. > > >>> That is much better, but still too slow, IMO. Think: it's the time >>> that it takes us to fontify a single windowful, only a couple of >>> dozens of lines. Why does it take so long? >> >> It does a very thorough job. > > > AFAIU, sm-c-mode doesn't. And it still takes tens of milliseconds. > >> For example, one bug fix from many years >> ago that I remember involved the fontification of foo in the following: >> >> .... >> int bar; >> } foo; >> >> What face should foo have? To answer that, you've got to go back over >> the brace expression to see what's there. If it's >> >> struct foo >> { >> int baz; >> .... >> >> , we need font-lock-variable-name-face for foo. On the other hand, if we >> have >> >> typedef struct foo >> { >> int baz; >> .... >> >> , we need font-lock-type-face. Before the bug fix, foo just got variable >> name face. scan-lists backward over the brace expression takes time, >> particularly for something the size of struct frame or even bigger. > > 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. 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? Maybe you'd be more interested in a basic c-mode that fontified only comments and strings, and that very quickly, but I wouldn't want that.