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: Thu, 10 Jun 2021 16:46:11 +0000 Message-ID: References: <83o8cge4lg.fsf@gnu.org> <62e438b5-d27f-1d3c-69c6-11fe29a76d74@dancol.org> <83fsxsdxhu.fsf@gnu.org> <83pmwudgw3.fsf@gnu.org> <83k0n2cjg5.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="26398"; 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: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jun 10 18:46:51 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 1lrNpS-0006ev-UT for ged-emacs-devel@m.gmane-mx.org; Thu, 10 Jun 2021 18:46:51 +0200 Original-Received: from localhost ([::1]:57356 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lrNpR-00088y-St for ged-emacs-devel@m.gmane-mx.org; Thu, 10 Jun 2021 12:46:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44536) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lrNow-0007Sq-82 for emacs-devel@gnu.org; Thu, 10 Jun 2021 12:46:18 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:28503 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1lrNot-0002GN-2t for emacs-devel@gnu.org; Thu, 10 Jun 2021 12:46:18 -0400 Original-Received: (qmail 63038 invoked by uid 3782); 10 Jun 2021 16:46:12 -0000 Original-Received: from acm.muc.de (p4fe15a63.dip0.t-ipconnect.de [79.225.90.99]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 10 Jun 2021 18:46:11 +0200 Original-Received: (qmail 6258 invoked by uid 1000); 10 Jun 2021 16:46:11 -0000 Content-Disposition: inline In-Reply-To: <83k0n2cjg5.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=unavailable 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:270654 Archived-At: Hello, Eli. On Thu, Jun 10, 2021 at 09:39:06 +0300, Eli Zaretskii wrote: > > 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. Yes, it does make a difference. On my machine, the times to scroll through xdisp.c with my favourite benchmark for font-lock-maximum-decoration set to 3, 2, 1 are 23s, 7.5s, 5.5s. > > 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? Maybe. It seems, though, that f-l-max-decoration is primarily about the degree of fontification applied, not its accuracy. > > > > "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? Well, I care for my own personal use, because the type fontifications help optically to separate the different parts of a function without needing to look too hard. The coloured bits are the variable declarations, to a zeroth order approximation. I suspect different users have very different needs here. Doesn't RMS run with font lock switched off (or is that just a rumour)? > > > 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. That would be difficult. Frequently a bug fix involves extensive code changes rather than simply a block of code one could put an `if' around. > > > 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? They're not of any particular kind. Any bug fix could slow CC Mode down marginally. Some have been known to speed it up. > If they only cause imperfect faces, I'm not sure it's unthinkable to > disable them, given some optional value of a user knob. Well, I've fixed around 550 bugs in CC Mode in the last 20 years. Identifying and reversing a subset of these to revert the performance would be difficult. > > 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. You could set it buffer locally in c-mode-common-hook, for example. It won't solve the basic problem, but it might brighten your day up. -- Alan Mackenzie (Nuremberg, Germany).