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: Thu, 10 Jun 2021 09:39:06 +0300 Message-ID: <83k0n2cjg5.fsf@gnu.org> References: <73ff18bf-66dc-7d7a-a0db-8edc2cdceba8@gmx.at> <83o8cge4lg.fsf@gnu.org> <62e438b5-d27f-1d3c-69c6-11fe29a76d74@dancol.org> <83fsxsdxhu.fsf@gnu.org> <83pmwudgw3.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7615"; 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 Thu Jun 10 08:40:18 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 1lrEMT-0001sT-Mp for ged-emacs-devel@m.gmane-mx.org; Thu, 10 Jun 2021 08:40:17 +0200 Original-Received: from localhost ([::1]:50352 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lrEMR-0003Tl-Nm for ged-emacs-devel@m.gmane-mx.org; Thu, 10 Jun 2021 02:40:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54576) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lrELi-0002nB-A5 for emacs-devel@gnu.org; Thu, 10 Jun 2021 02:39:30 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38546) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lrELf-0008IF-Cx; Thu, 10 Jun 2021 02:39:27 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3207 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 1lrELZ-0005Q7-9w; Thu, 10 Jun 2021 02:39:21 -0400 In-Reply-To: (message from Alan Mackenzie on Wed, 9 Jun 2021 21:03:03 +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:270628 Archived-At: > Date: Wed, 9 Jun 2021 21:03:03 +0000 > Cc: dancol@dancol.org, monnier@iro.umontreal.ca, rudalics@gmx.at, > emacs-devel@gnu.org, rms@gnu.org > From: Alan Mackenzie > > > 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. > > That variable is still supported by CC Mode (with the exception of AWK > Mode, where it surely is not needed). Does it make a difference, performance-wise? If not (which is what ISTR), then that variable isn't really "supported", because supporting it means that different values of it cause tangible differences in performance. > Another possibility would be to replace accurate auxiliary functionality > with rough and ready facilities. In a scroll through xdisp.c, fontifying > as we go, the following three functions are taking around 30% of the > run-time: > > (i) c-bs-at-toplevel-p, which determines whether or not a brace is at the > top level. > (ii) c-determine-limit, c-determine-+ve-limit, which determine search > limits approximately ARG non-literal characters before or after point. > > By replacing these accurate functions with rough ones, the fontification > would be right most of the time, but a mess at other times (for example, > when there are big comments near point). (i) is more important for C++ > that C, but still makes a difference in C. > > If we were to try this, I think a user toggle would be needed. How about making font-lock-maximum-decoration control that as well? > > > "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? > > Because many users will still want at least the basic types (int, double, > unsigned long, ....) fontified I'm not sure. Can you explain why would I care too much about the basic types (or types in general) standing out? > > 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. > > I think this would be a bad thing. There are no (or very few) similar > user options in CC Mode at the moment, and an option to fix or not fix a > bug seems a strange idea It depends on the bug. If the bug causes Emacs to infloop or work very slowly, then sure, no toggle for the fix would make sense. But I was talking about "bugs" that cause inaccurate or incorrect fontifications, and those are much "softer". At least IMO such "bugs" are tolerable if they are rare enough, especially if fixing them hurts redisplay performance and Emacs responsiveness in general. Don't forget that the display code invokes fontifications also when it does internal layout calculations whose results are not immediately shown (or even not at all). When that happens, some command not directly related to display could be adversely affected. So one idea would be to turn off these expensive parts in those cases. > > 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 punishment is rarely too harsh for a single bug. But a lot of 2%s, > 3%s or 5%s add up over time. If we were to outlaw a "3% fix", then many > bugs would just be unsolvable. Once again: what kind of "bugs" are those? If they only cause imperfect faces, I'm not sure it's unthinkable to disable them, given some optional value of a user knob. > Do you have fast-but-imprecise-scrolling enabled? No. That's a separate issue, and influences all the modes, even those where font-lock is light-weight.