bug#62339: cc-mode fontifies variables incorrectly when const follows type

[Eli Zaretskii <eliz@gnu.org>]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Alan Mackenzie <acm@muc.de>,  <62339@debbugs.gnu.org>,  Eli Zaretskii
>  <eliz@gnu.org>
> Date: Thu, 23 Mar 2023 13:45:21 +0800
> 
> Daniel Colascione <dancol@dancol.org> writes:
> 
> > Yes, we can  We lived with the old behavior for decades. We can live with it a few weeks longer.
> 
> I reported this bug because I saw such code in use.
> 
> > Give me a break. No, you don't.
> 
> I do.  I *see* code making use of implicit int every day.
> 
> > Practically nobody uses this obscure and deprecated C feature. If
> > people did, we'd have addressed the problem years ago.
> 
> Who does ``we'' refer to?
> 
> Put bluntly, you have no right to decide what C code I see or write, or
> what C code Alan wants to support.  Declarations consisting of only a
> storage class specifier are part of the 1989 C Standard.
> 
> This bug is no more important than bug#59267, and both will have to be
> fixed and stay fixed.

This argument is pointless.  Getting "blunt" (a.k.a. "rude") over that
is certainly uncalled for.  Anyone can make a local change in the
relevant Lisp code if what happens in the repository doesn't suit
him/her.  Making a local copy of whatever cc-*.el file which causes
this is very easy, and won't even cause any merge conflicts in the
future, if you want to avoid it.  Or make a local branch with that
change and periodically merge from master.  Or any other of the
possible solutions.

So please don't continue arguing whose use case is more important.
Alan will decide whether backing out the offending "fix" is
reasonable, and people who track the master branch should live with
that until a better solution is found.