Re: CC Mode troubles and Emacs 29

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> That's the problem.  Clearly you prefer the former (all bug reports in
> the long list that Alan shared were filed by you), and others prefer
> the latter.  There is a tension between fontifying too few identifiers
> with a type face and fontifying too many identifiers with a type face.
> And that problem cannot have an accurate solution without a parser.

One involves me doing nothing at all.  The other results in massive
green splotches appearing in my code.

There is also no such tension because I have not heard of this problem
occurring in any other editor in the past.

> Alan did not add a defcustom around that new feature (and rightly so,
> AFAIU), but you can also turn it off with a single short line in your
> init file:
>
> (advice-add #'c-fontify-new-found-type :override #'ignore)

That is not a solution, because the feature will still be broken for
everyone else.  And at work everyone is more or less forced to use the
same provisioned site-init file.

> Evidently that's your opinion and preference, and it's not what others
> prefer: they are more annoyed by type identifiers that remain
> unfontified than by occasional fontification of non-type identifiers
> as types.

Most people I asked, at my day job, find the current situation of CC
Mode laughable.  It is immediately obvious to any other C programmer who
begins to use Emacs 29 for real work, where it is necessary to
continuously work on large C files for periods longer than 5 minutes at
a time.  When doing that, random misfontification does not even happen
with the toy text editor that is part of GNOME, but it does with Emacs
29.

And very quickly.  In one example I just sent, `fprintf' was turned into
a type within 5 minutes of beginning to edit a file.  I don't know how,
because I noticed too late to get the lossage.

Sadly, the reason nobody else has reported this bug is because working
with Emacs development is more or less incompatible with a full time
job.  It takes quite an effort to find a reproducer, report a bug, and
then argue with people like you who insist it is not a bug and argue
against the easy way to fix it in time for the release, so why do that
when I already am?  (Notice that the actual maintainer of CC Mode agrees
that it is a serious bug, so your arguing is essentially a waste of
time, of exactly the sort that drives people away from Emacs
development.)

Previously, nothing was broken.  The status quo was with us since font
lock in C code first existed, back then CC Mode did not even make an
effort to fontify types.  It is still there, with us, on the Emacs 28
branch.

If people want to make CC Mode fontify more types, that is fine.
But nobody in the thread you linked has said he prefers identifiers
being fontified as types to some types not being fontified at all.

> Sorry, I don't understand what you mean by this, or how it is related
> to the problem at hand.

c-ts-mode, the so-called ``fontification based on an actual parser'',
does not work for me.  I explained why before, and it will take a long
time for it to become a useful substitute for CC Mode, seeing as it
until recently (this was fixed just a few days ago) experienced problems
with code along the lines of:

typedef struct {
    unsigned long flags;
    unsigned long functions;
    unsigned long decorations;
    long input_mode;
    unsigned long status;
} PropMotifWmHints;

Which is a structure copied absolutely everywhere throughout X programs.