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: Wed, 09 Jun 2021 19:21:23 -0700 Message-ID: <179f3aca300.2816.cc5b3318d7e9908e2c46732289705cb0@dancol.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> 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="35645"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: AquaMail/1.29.2-1810 (build: 102900008) Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, rms@gnu.org, emacs-devel@gnu.org To: Alan Mackenzie , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jun 10 04:24:01 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 1lrAMT-00094r-2N for ged-emacs-devel@m.gmane-mx.org; Thu, 10 Jun 2021 04:24:01 +0200 Original-Received: from localhost ([::1]:56230 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lrAMS-00030b-0b for ged-emacs-devel@m.gmane-mx.org; Wed, 09 Jun 2021 22:24:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40350) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lrAK6-0001a4-Kw for emacs-devel@gnu.org; Wed, 09 Jun 2021 22:21:34 -0400 Original-Received: from dancol.org ([2600:3c01:e000:3d8::1]:56902) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lrAK2-0006jD-Uu; Wed, 09 Jun 2021 22:21:34 -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=iamrUQgrXSXnYEcuSDXpu9OkcTNzrEhCq2LvJKuWg6c=; b=mbSROxbAnycuc2ssH+DazkFQtI 0mqmiYjvAqt+ldUz5rX8V0JqAGQvqIk5nljz+ldW9fMZwTKnZOLZ5NS1vrWySilgYPCxcUMFfTD1Q tXLWv+mATiWAREWGeTPw05HfgBoHFXraGgKYWw59g8bbu56PqALQdE7aTQv2N32HYUUpdU1LTrlRY tlA730MNY1eEFdOhxzzfPP8f2pEzg0JEFisE8faTxpl/hz/4NwbiIVJVX08GaIE5EooGmOACUwaBd VwteXCB9dzWlFS/YlxxPmb4CiyzEaXBBdNxq5S9f5AuuCQ0jSw+fp51E1mi9SPlZyrg1inFYPDY6v L99LlbvQ==; Original-Received: from 210.sub-174-193-192.myvzw.com ([174.193.192.210]:3113 helo=[100.104.170.157]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.89) (envelope-from ) id 1lrAJx-0003K5-60; Wed, 09 Jun 2021 19:21:25 -0700 In-Reply-To: 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:270623 Archived-At: On June 9, 2021 2:03:07 PM Alan Mackenzie wrote: > Hello, Eli. > > On Wed, Jun 09, 2021 at 21:36:44 +0300, Eli Zaretskii wrote: >>> 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. > > That variable is still supported by CC Mode (with the exception of AWK > Mode, where it surely is not needed). > > 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 i Another option is adding core support to speed up these operations. I don't think we should be sacrificing correctness for speed. > > > If we were to try this, I think a user toggle would be needed. > >>>>> 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? > > Because many users will still want at least the basic types (int, double, > unsigned long, ....) fontified, leading to the very mess Daniel would > like to avoid. Declarations with basic types tend to be interleaved > with those using project defined types. > >>>> 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. > > OK. My above suggestion might give ~50% increase in fontification speed. > >>> 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. > > 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, and would make the code quite a bit more > complicated. > >> 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 is some truth in this imputation, yes. > >>> 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 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. > >>>> 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. > > Thanks. I'll try to come up with speedups in the coming weeks (and > months). > > Do you have fast-but-imprecise-scrolling enabled? That can reduce the > pain. > > -- > Alan Mackenzie (Nuremberg, Germany).