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: Daniel Colascione
Subject: Re: cc-mode fontification feels random
Date: Tue, 8 Jun 2021 11:11:21 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1

On 6/8/21 9:36 AM, Stefan Monnier wrote:

All I meant is that given the increase of performance of CPUs (until the
beginning of this century) and a non-corresponding increase in file size
and complexity of language syntax, programmers nowadays prefer correct
behavior over fast behavior, since the correct behavior is fast enough
anyway to be bearable.
Not in CC Mode, not IMO anyway.  But perhaps you don't consider what
CC Mode does to be "correct behavior".
My comment was about using hacks like
`open-paren-in-column-0-is-defun-start` to avoid scanning from BOB in
`syntax-ppss/propertize`.

And then, of course, there's a question "what is correct"?  When I see
something like

    static foo_t __attribute__((bar)) myvar;

I'm not sure I'd care if everything before "myvar" would be in the
same face and "myvar" in another face.  IOW, it isn't necessarily
important to me that fontification knows that foo_t is a type and not
a keyword.  So searching the file (and perhaps other files) for the
definition of foo_t isn't important -- for the purposes of
fontification.
FWIW, my `font-lock-type-face` is customized to:

     '(font-lock-type-face ((t)))

so I'll let you guess my opinion on this ;-)

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.

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.







reply via email to

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