[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cc-mode fontification feels random
From: |
Alan Mackenzie |
Subject: |
Re: cc-mode fontification feels random |
Date: |
Thu, 10 Jun 2021 16:46:11 +0000 |
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 <acm@muc.de>
> > > 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).
- Re: cc-mode fontification feels random, (continued)
- Re: cc-mode fontification feels random, Dmitry Gutov, 2021/06/09
- Re: cc-mode fontification feels random, Alan Mackenzie, 2021/06/09
- Re: cc-mode fontification feels random, Daniel Colascione, 2021/06/09
- Re: cc-mode fontification feels random, Eli Zaretskii, 2021/06/10
- Re: cc-mode fontification feels random, Daniel Colascione, 2021/06/10
- Re: cc-mode fontification feels random, Eli Zaretskii, 2021/06/10
- Re: cc-mode fontification feels random, Eli Zaretskii, 2021/06/10
- Re: cc-mode fontification feels random,
Alan Mackenzie <=
- Re: cc-mode fontification feels random, Eli Zaretskii, 2021/06/10
- Re: cc-mode fontification feels random, Daniel Colascione, 2021/06/10
- Re: cc-mode fontification feels random, Eli Zaretskii, 2021/06/10
- Re: cc-mode fontification feels random, Daniel Colascione, 2021/06/10
- Re: cc-mode fontification feels random, Eli Zaretskii, 2021/06/10
- Re: cc-mode fontification feels random, Óscar Fuentes, 2021/06/10
- Re: cc-mode fontification feels random, Eli Zaretskii, 2021/06/10
- Re: cc-mode fontification feels random, Alan Mackenzie, 2021/06/11
- Re: cc-mode fontification feels random, Eli Zaretskii, 2021/06/11
- Re: cc-mode fontification feels random, Daniel Colascione, 2021/06/11