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.