Re: CC Mode troubles and Emacs 29

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> It's indeed exaggerated, AFAIU.  Basically, it's an effect of the
> c-fontify-new-found-type function, which was added to CC Mode in Oct
> 2021 because of this thread:

It's not exaggerated at all.  After 20 minutes to an hour of work, C
Mode must be turned on and off again.

> https://lists.gnu.org/archive/html/emacs-devel/2021-06/msg00174.html.

Yes, because of the long ensuing thread from there on, C Mode is now
much more annoying to work with than it was in Emacs 28.

Previously, CC Mode fontification was missing some types.  Judge for
yourself what is better: missing types, or randomly adding types?

> A simple recipe is this:
>
> emacs -Q
> C-x C-f foo.c
>
> and type:
>
> int main () { int foo; foo = 1; }
> typedef foo SPC
>
> Now 'foo' in 'foo = 1' is fontified in green, because CC Mode
> considers that 'foo' is a type.  If you now realize that 'foo' is a
> typo, and that what you actually meant is 'foobar', and correct that
> typo with DEL bar, 'foo' in 'foo = 1' does not loose its type
> fontification.  And if you do that often enough, in the end the buffer
> is "filled with green splotches". Note that this can easily be fixed
> with C-u C-x x f C-x x f.

Or re-enabling C Mode.  Both of which are annoying things that weren't
necessary in Emacs 28.

And that's not the only situation under which incorrect recognition of
types occurs.  Sometimes, CC Mode will recognize a random identifier in
an incompletely entered statement as a type.  Most of that was fixed in
November, but there's one or two which have not been fixed that I
haven't been able to reproduce consistently.

> It's actually a nice example of the inherent limits of a fontification
> that is not based on an actual parser.

It worked in Emacs 28, 27, and since before that, because it really is
not vital for CC Mode to proactively look for types.

AFAIU tree-sitter has the same problem: it does not understand typedefs
previously encountered in a buffer, so in the following piece of code:

IV_reset_1603 (regRange, regBlock, t2busProbe)
        long    regBlock;
        Handle  t2busProbe;
{
  register *BP, *DP;

  /* ... */
}

it cannot know whether or not `regRange' is a typedef name or an
identifier.  (This is a big problem with parsing the C language in
general.)

Or in the following Java code:

import org.gnu.emacs.EmacsActivity;

where whether or not `EmacsActivity' is a type name is ambiguous: it
could have as well been part of a package name.  Java is particularly
nasty because the only way to know what `EmacsActivity' is is by looking
at the file system.  Yet the CC Mode type discovery happens to work very
well in Java, resulting in consistently fontified blocks of import
statements.

Besides, Alan says he already has a fix, so I would hardly call it an
inherent limit of anything.

In the meantime, the so-called ``fontification based on an actual
parser'' does not even understand traditional C code.  Last I checked,
it also had problems indenting the Motif WM hints structure that people
copy everywhere.