emacs-devel
[Top][All Lists]
Advanced

[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: Wed, 9 Jun 2021 20:20:26 +0000

Hello, Daniel.

On Wed, Jun 09, 2021 at 12:05:27 -0700, Daniel Colascione wrote:

> On June 9, 2021 11:23:04 AM Alan Mackenzie <acm@muc.de> wrote:

> > Hello, Eli.

> > On Tue, Jun 08, 2021 at 21:25:49 +0300, Eli Zaretskii wrote:
> >>> From: Daniel Colascione <dancol@dancol.org>
> >>> Date: Tue, 8 Jun 2021 11:11:21 -0700
> >>> Cc: rudalics@gmx.at, emacs-devel@gnu.org, rms@gnu.org, acm@muc.de

> >>> The whole point of fontification is to provide visual hints about
> >>> the semantic structure of source code. If cc-mode can't do that
> >>> reliably, my preference would be for it to not do it at all.
> >>> Fontification of a type-using expression shouldn't change if I move
> >>> the definition of that type from one file to another.

> >> 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.

> >>> 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.



> I think it would be better in fact. The whole point of fontification is to 
> provide visual clues about the function of a word in a buffer.

That's one of the points.  Another point is to provide colour, thus
giving the eye some pattern to orient around.  I think its most important
function is to point out comments, thus making things like

    if (foo)
      bar (); /* comment about bar
    else
      baz (); /* comment about baz */
    
undangerous.  For that case, fine distinctions about types are
irrelevant.

> If I can't rely on font lock type face actually distinguishing types
> from non-types, what's the point?

Because the information about types, though imperfect, is nevertheless
highly useful.

> If fontification isn't reliable, it's not syntax highlighting, but
> instead a kewl rainbow effect.

Now you seem to be saying that either font lock has to be 100% right, or
it's wholly useless.  Is that a fair summary of your position?  If so, do
you disable font lock mode for CC Mode and other modes which can't
guarantee perfect font locking?

> ISTM we can only correctly do fontification of type references with the 
> help of LSP.

I don't think it would be sensible to try to do it otherwise.

> Without LSP support, I'd rather we not try to get it right, sometimes
> get it wrong, and make font-lock-type-face unreliable.  (We can
> correctly fontify declarations and definitions I think.)

That's a rather negative way of putting things, which is a bit indefinite
and wishy-washy.  You could instead try to specify which tokens should get
font-lock-type-face and which shouldn't, thus giving something concrete
to discuss.  I think this will be difficult to do well, and may lead to
the result which I alluded to above.

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]