CC Mode troubles and Emacs 29

CC Mode troubles and Emacs 29

[Po Lu]

Alan, all,

Emacs 29 is supposed to have pretests released in around a month.
However, CC Mode is still prone to misidentifying typos as types.

That is a major regression from the standpoint of users.  So, perhaps it
would be prudent to disable automatic type finding on the emacs-29
branch, and to keep working on it in the CC Mode repository?

Thanks.

Re: CC Mode troubles and Emacs 29

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Alan Mackenzie <acm@muc.de>
> Date: Mon, 09 Jan 2023 17:51:38 +0800
> 
> Alan, all,
> 
> Emacs 29 is supposed to have pretests released in around a month.
> However, CC Mode is still prone to misidentifying typos as types.
> 
> That is a major regression from the standpoint of users.  So, perhaps it
> would be prudent to disable automatic type finding on the emacs-29
> branch, and to keep working on it in the CC Mode repository?

Is there a bug number for this issue? if so, could you please tell
what it is?

If there's no bug number, please file one with recipe for reproducing
the problem, and let's take it from there.

Thanks.

Re: CC Mode troubles and Emacs 29

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Is there a bug number for this issue? if so, could you please tell
> what it is?

It's on the CC Mode bug tracker:

  https://sourceforge.net/p/cc-mode/mailman/message/37737197/

Unfortunately, Alan seems to be too busy these days to finish that work.

Re: CC Mode troubles and Emacs 29

[Alan Mackenzie]

Hello, Po.

On Mon, Jan 09, 2023 at 21:49:20 +0800, Po Lu wrote:
> Eli Zaretskii <eliz@gnu.org> writes:

> > Is there a bug number for this issue? if so, could you please tell
> > what it is?

One of the bugs is bug #59671.

> It's on the CC Mode bug tracker:

>   https://sourceforge.net/p/cc-mode/mailman/message/37737197/

> Unfortunately, Alan seems to be too busy these days to finish that work.

Well, actually, I've been taking a break from Emacs the last two or
three weeks.

In the last communication for bug #59671, on 2022-12-09, you replied:

>>> This works for my example but I've yet to use the patch in the real
>>> world.  Thanks.

Have you now anything to add to that?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: CC Mode troubles and Emacs 29

[Eli Zaretskii]

> Date: Mon, 9 Jan 2023 15:48:12 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> On Mon, Jan 09, 2023 at 21:49:20 +0800, Po Lu wrote:
> > Eli Zaretskii <eliz@gnu.org> writes:
> 
> > > Is there a bug number for this issue? if so, could you please tell
> > > what it is?
> 
> One of the bugs is bug #59671.

I see no user-facing problems with the recipe there.  It sounds like
you are discussing some internal feature of CC mode that potentially
misbehaves in that case.  Why should I, as a user, care?  More
importantly, why should I, as an Emacs maintainer, be worried due to
this problem, which Po Lu described as a "major regression"?  I don't
even see a regression, let alone a major one.  What did I miss?

Re: CC Mode troubles and Emacs 29

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Mon, 9 Jan 2023 15:48:12 +0000
>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>> From: Alan Mackenzie <acm@muc.de>
>> 
>> On Mon, Jan 09, 2023 at 21:49:20 +0800, Po Lu wrote:
>> > Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > > Is there a bug number for this issue? if so, could you please tell
>> > > what it is?
>> 
>> One of the bugs is bug #59671.
>
> I see no user-facing problems with the recipe there.  It sounds like
> you are discussing some internal feature of CC mode that potentially
> misbehaves in that case.  Why should I, as a user, care?  More
> importantly, why should I, as an Emacs maintainer, be worried due to
> this problem, which Po Lu described as a "major regression"?  I don't
> even see a regression, let alone a major one.  What did I miss?

That's just one bug of many.  If you look at the CC Mode bug tracker for
November, you'll see a lot of bugs that boil down to this: after 25 to
60 minutes of editing in a buffer, the entire buffer is filled with
green splotches (making fontification useless) and C Mode has to be
re-enabled, because CC Mode keeps misrecognizing and fontifying
identifiers as types.

Thanks.

Re: CC Mode troubles and Emacs 29

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Alan Mackenzie <acm@muc.de>,  emacs-devel@gnu.org
> Date: Tue, 10 Jan 2023 09:05:36 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Date: Mon, 9 Jan 2023 15:48:12 +0000
> >> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> >> From: Alan Mackenzie <acm@muc.de>
> >> 
> >> On Mon, Jan 09, 2023 at 21:49:20 +0800, Po Lu wrote:
> >> > Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> > > Is there a bug number for this issue? if so, could you please tell
> >> > > what it is?
> >> 
> >> One of the bugs is bug #59671.
> >
> > I see no user-facing problems with the recipe there.  It sounds like
> > you are discussing some internal feature of CC mode that potentially
> > misbehaves in that case.  Why should I, as a user, care?  More
> > importantly, why should I, as an Emacs maintainer, be worried due to
> > this problem, which Po Lu described as a "major regression"?  I don't
> > even see a regression, let alone a major one.  What did I miss?
> 
> That's just one bug of many.  If you look at the CC Mode bug tracker for
> November, you'll see a lot of bugs that boil down to this: after 25 to
> 60 minutes of editing in a buffer, the entire buffer is filled with
> green splotches (making fontification useless) and C Mode has to be
> re-enabled, because CC Mode keeps misrecognizing and fontifying
> identifiers as types.

If this is so, I find it strange that we don't have heaps of bug
reports about this in our bug tracker.  I doubt that anyone could
ignore the terrible misbehavior you describe, if indeed the
description is accurate and not exaggerated.

I guess we will have to wait till the pretest to see how bad that is
in practice.

Re: CC Mode troubles and Emacs 29

[Gregory Heytings]

>
> If this is so, I find it strange that we don't have heaps of bug reports 
> about this in our bug tracker.  I doubt that anyone could ignore the 
> terrible misbehavior you describe, if indeed the description is accurate 
> and not exaggerated.
>

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: 
https://lists.gnu.org/archive/html/emacs-devel/2021-06/msg00174.html.  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.

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

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.

Re: CC Mode troubles and Emacs 29

[Po Lu]

[-- Attachment #1: Type: text/plain, Size: 507 bytes --]

Po Lu <luangruo@yahoo.com> writes:

> 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.

And just to demonstrate the severe nature of the problem, within _five_
minutes of working on a file, `fprintf' turns into a type:


[-- Attachment #2: Screenshot from 2023-01-11 09-45-24.png --]
[-- Type: image/png, Size: 34450 bytes --]

Re: CC Mode troubles and Emacs 29

[Gregory Heytings]

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

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.  (In fact, even 
a parser is not enough for that job if you want 100% accuracy.)

>> 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.
>

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)

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

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.

>
> AFAIU tree-sitter has the same problem: it does not understand typedefs 
> previously encountered in a buffer
>

Yes, as I said above if you want 100% accuracy, you need more than a 
parser, you need a full compiler.

>
> 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.
>

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

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.

Re: CC Mode troubles and Emacs 29

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  acm@muc.de,  emacs-devel@gnu.org
> Date: Wed, 11 Jan 2023 18:12:32 +0800
> 
> Gregory Heytings <gregory@heytings.org> writes:
> 
> > 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.

Why do you guys keep arguing about this so much?  Didn't Alan just fix
this issue?  And if he still didn't, he said he'd try fixing it before
Emacs 29 is released.  So what is there to argue about?

Re: CC Mode troubles and Emacs 29

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Didn't Alan just fix this issue?

No, not yet.  But he said he would.

> And if he still didn't, he said he'd try fixing it before
> Emacs 29 is released.  So what is there to argue about?

That's what I thought until I saw Gregory's response in my inbox.

Re: CC Mode troubles and Emacs 29

[Gregory Heytings]

>> So what is there to argue about?
>
> That's what I thought until I saw Gregory's response in my inbox.
>

Nonetheless, you replied to what I posted _before_ Alan said he would fix 
this with two posts.

Re: CC Mode troubles and Emacs 29

[Alan Mackenzie]

Hello, Eli.

On Tue, Jan 10, 2023 at 14:57:04 +0200, Eli Zaretskii wrote:
> > From: Po Lu <luangruo@yahoo.com>
> > Cc: Alan Mackenzie <acm@muc.de>,  emacs-devel@gnu.org
> > Date: Tue, 10 Jan 2023 09:05:36 +0800

> > Eli Zaretskii <eliz@gnu.org> writes:

> > >> Date: Mon, 9 Jan 2023 15:48:12 +0000
> > >> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> > >> From: Alan Mackenzie <acm@muc.de>

[ .... ]

> > >> One of the bugs is bug #59671.

[ .... ]

> > That's just one bug of many.  If you look at the CC Mode bug tracker for
> > November, you'll see a lot of bugs that boil down to this: after 25 to
> > 60 minutes of editing in a buffer, the entire buffer is filled with
> > green splotches (making fontification useless) and C Mode has to be
> > re-enabled, because CC Mode keeps misrecognizing and fontifying
> > identifiers as types.

> If this is so, I find it strange that we don't have heaps of bug
> reports about this in our bug tracker.

We do have such heaps, where "this" is understood to be about the
fontification bugs, one of which Gregory accurately summarised.

Some of these bugs are 58534, 58537, 58795, 58796, 58772, 58883, 59032,
59070, 59233, 59267, 59051, 59427, which have all been fixed.
Additionally there are 59234, 59671 (the bug mentioned earlier) for which
patches are available but not yet committed, and 59216, for  which there
is, as yet, no patch.

> I doubt that anyone could ignore the terrible misbehavior you describe,
> if indeed the description is accurate and not exaggerated.

I don't think there was exaggeration, here.

> I guess we will have to wait till the pretest to see how bad that is
> in practice.

Why shouldn't I fix it before the pretest?  As mentioned above, the patch
is available.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: CC Mode troubles and Emacs 29

[Eli Zaretskii]

> Date: Tue, 10 Jan 2023 17:37:18 +0000
> Cc: Po Lu <luangruo@yahoo.com>, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > I guess we will have to wait till the pretest to see how bad that is
> > in practice.
> 
> Why shouldn't I fix it before the pretest?

I hope you will, indeed.  But you should know that there's not a lot
of time left for that.

Re: CC Mode troubles and Emacs 29

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org,  acm@muc.de
> Date: Mon, 09 Jan 2023 21:49:20 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Is there a bug number for this issue? if so, could you please tell
> > what it is?
> 
> It's on the CC Mode bug tracker:
> 
>   https://sourceforge.net/p/cc-mode/mailman/message/37737197/

I don't see any recipe there that demonstrates the problems.

Re: CC Mode troubles and Emacs 29

[Gregory Heytings]

>
> https://sourceforge.net/p/cc-mode/mailman/message/37737197/
>

In that thread you say:

>
> Tree-sitter has many problems.  For one, it does not intend to support 
> C89 or (more importantly for me) pre-standard C.
>

That's not a tree-sitter problem per se, it's "only" a matter of someone 
taking the time to define a tree-sitter grammar for these variants of the 
C language.  What is not possible is to define "one grammar to rule them 
all", IOW, one grammar that would magically recognize in which variant of 
the C language a given file is written.

Re: CC Mode troubles and Emacs 29

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

>>
>> https://sourceforge.net/p/cc-mode/mailman/message/37737197/
>>
>
> In that thread you say:

So please reply there.  :)

> That's not a tree-sitter problem per se, it's "only" a matter of
> someone taking the time to define a tree-sitter grammar for these
> variants of the C language.  What is not possible is to define "one
> grammar to rule them all", IOW, one grammar that would magically
> recognize in which variant of the C language a given file is written.

CC Mode happens to do that fine.

Re: CC Mode troubles and Emacs 29

[Gregory Heytings]

>> That's not a tree-sitter problem per se, it's "only" a matter of 
>> someone taking the time to define a tree-sitter grammar for these 
>> variants of the C language.  What is not possible is to define "one 
>> grammar to rule them all", IOW, one grammar that would magically 
>> recognize in which variant of the C language a given file is written.
>
> CC Mode happens to do that fine.
>

I fear you contradict yourself.  You cannot say, in a thread which you 
started to explain that CC Mode fontification is broken (it "fills the 
buffer with green splotches (making fontification useless)"), that CC Mode 
fontification works fine.

Re: CC Mode troubles and Emacs 29

[Alan Mackenzie]

Hello, Gregory.

On Tue, Jan 10, 2023 at 10:06:32 +0000, Gregory Heytings wrote:

> >> That's not a tree-sitter problem per se, it's "only" a matter of 
> >> someone taking the time to define a tree-sitter grammar for these 
> >> variants of the C language.  What is not possible is to define "one 
> >> grammar to rule them all", IOW, one grammar that would magically 
> >> recognize in which variant of the C language a given file is written.

> > CC Mode happens to do that fine.

> I fear you contradict yourself.  You cannot say, in a thread which you 
> started to explain that CC Mode fontification is broken (it "fills the 
> buffer with green splotches (making fontification useless)"), that CC Mode 
> fontification works fine.

There is no contradiction in what Po said.  The fact that CC Mode
fontification has bugs in no way contradicts its ability to parse older
variants of C as well as newer ones.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: CC Mode troubles and Emacs 29

[Alan Mackenzie]

Hello, Po.

On Mon, Jan 09, 2023 at 17:51:38 +0800, Po Lu wrote:
> Alan, all,

> Emacs 29 is supposed to have pretests released in around a month.
> However, CC Mode is still prone to misidentifying typos as types.

Yes.  I can see my way to having this fixed in a small number of weeks,
or a large number of days.  The bug is understood.

> That is a major regression from the standpoint of users.

Yes, I agree with that.

> So, perhaps it would be prudent to disable automatic type finding on
> the emacs-29 branch, and to keep working on it in the CC Mode
> repository?

No, this wouldn't be a good idea.  It would be an appreciable amount of
work, and would leave around 50% of types unfontified.  This would very
quickly cause bug reports.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).