From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: cc-mode fontification feels random Date: Wed, 09 Jun 2021 21:36:44 +0300 Message-ID: <83pmwudgw3.fsf@gnu.org> References: <83lf7mhl3n.fsf@gnu.org> <73ff18bf-66dc-7d7a-a0db-8edc2cdceba8@gmx.at> <83o8cge4lg.fsf@gnu.org> <62e438b5-d27f-1d3c-69c6-11fe29a76d74@dancol.org> <83fsxsdxhu.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2160"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rudalics@gmx.at, dancol@dancol.org, monnier@iro.umontreal.ca, rms@gnu.org, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jun 09 20:37:47 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 1lr35G-0000M5-II for ged-emacs-devel@m.gmane-mx.org; Wed, 09 Jun 2021 20:37:46 +0200 Original-Received: from localhost ([::1]:32886 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lr35F-0002zZ-J4 for ged-emacs-devel@m.gmane-mx.org; Wed, 09 Jun 2021 14:37:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60832) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lr34k-0002KG-1g for emacs-devel@gnu.org; Wed, 09 Jun 2021 14:37:14 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51534) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lr34h-0003so-B0; Wed, 09 Jun 2021 14:37:11 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2817 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lr34W-0004YH-Kd; Wed, 09 Jun 2021 14:37:02 -0400 In-Reply-To: (message from Alan Mackenzie on Wed, 9 Jun 2021 18:22:57 +0000) 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:270605 Archived-At: > Date: Wed, 9 Jun 2021 18:22:57 +0000 > Cc: Daniel Colascione , monnier@iro.umontreal.ca, > rudalics@gmx.at, emacs-devel@gnu.org, rms@gnu.org > From: Alan Mackenzie > > > I think we agree. Except that for me, it should also not try if it > > cannot do it quickly enough, not only reliably enough. > > Quickly and reliably enough are desirable things, but in competition > with eachother. Reliably enough is a lot easier to measure, quickly > enough depends on the machine, the degree of optimisation, and above > all, the user's expectations. That's why we had (and still have) font-lock-maximum-decoration: so that users could control the tradeoff. Unfortunately, support for that variable is all but absent nowadays, because of the widespread mistaken assumption that font-lock is fast enough in all modes. > > > IMHO, we should rely on LSP to figure out what symbols are types, and if > > > a LSP isn't available, we shouldn't try to guess. > > "Shouldn't try to guess" means taking a great deal of > font-lock-type-faces out of CC Mode. I don't honestly think the end > result would be any better than what we have at the moment. You don't think it will be better for what reason? > > I was talking about what to do (or not to do) with our existing > > regexp- and "syntax"-based fontifications. I still remember the days > > when CC Mode handled that well enough without being a snail it > > frequently is now, and that was on a machine about 10 times slower > > than the one I use nowadays. > > Those old versions had masses of fontification bugs in them. I don't remember bumping into those bugs. Or maybe they were not important enough to affect my UX. Slow redisplay, by contrast, hits me _every_day_, especially if I need to work with an unoptimized build. From where I stand, the balance between performance and accuracy have shifted to the worse, unfortunately. > People wrote bug reports about them and they got fixed. Those fixes > frequently involved a loss of speed. :-( If there's no way of fixing a bug without adversely affecting speed, we should add user options to control those "fixes", so that people could choose the balance that fits them. Sometimes Emacs could itself decide whether to invoke the "slow" code. For example, it makes no sense for users of C to be "punished" because we want more accurate fontification of C++ sources. > There have also been several bug reports about unusual buffers getting > fontified at the speed of continental drift, and fixing those has > usually led to a little slowdown for ordinary buffers. I'm thinking, > for example, about bug #25706, where a 4 MB file took nearly an hour to > scroll through on my machine. After the fix, it took around 86 seconds. Once again, a pathological use case should not punish the usual ones; if the punishment is too harsh, there should be a way to disable the support for pathological cases for those who never hit them. > > The C language didn't change too much since then, at least not the > > flavor I frequently edit. > > There are two places where CC Mode can be slow: font locking large areas > of text, and keeping up with somebody typing quickly. Which of these > bothers you the most? I have plans for speeding up one of these. Both, I guess. Though the former is probably more prominent, since I'm not really such a fast typist, but I do happen to scroll through source quite a lot.