bug#58883:

Alan Mackenzie <[email protected]> Thu, 10 Nov 2022 14:13:14 +0000
Newsgroups gmane.emacs.cc-mode.general
Message-ID <Y20G+tQvvtn3+Eif@ACM>
Hello, Po.

On Wed, Nov 09, 2022 at 08:40:48 +0800, Po Lu via CC-Mode-help wrote:
> Alan Mackenzie <[email protected]> writes:

> > On Tue, Nov 08, 2022 at 20:29:30 +0800, Po Lu wrote:
> >> Alan Mackenzie <[email protected]> writes:

> >> > I'm gradually fixing it.

> >> Thanks.  I hope Emacs 29 will not be released without the fix.

> >> > The mechanism is that when C Mode sees what it takes to be a type, from
> >> > the context, c-forward-type returns the symbol 'maybe.

> >> > Later on in the processing, the analysis of the C code "confirms" that
> >> > this 'maybe actually is a type, and it gets promoted to 'found, and
> >> > entered into the c-found-types list.  At the same time, other occurrences
> >> > of the type throughout the buffer are fontified as types.

> >> > This mechanism is not foolproof, and goes wrong when a statement is
> >> > partially typed.  Rather than correcting the mistakenly fontified
> >> > "types", which would be more difficult, I'm concentrating on not
> >> > promoting a 'maybe type to a 'found type too enthusiasically.

> >> Right, but there are some things that simply cannot work with that
> >> approach.  Imagine the following code being typed by the user:

> >> foo (ptr)
> >>      struct foobar *ptr;
> >> {
> >>   register struct frobar *ptr_fast;

> >>   ptr_fast = ptr;

> >> only for him to realize that "oops, struct frobar is not a type!" and
> >> correct it to:

> >>   register struct foobar *ptr_fast;

> >> by which time it is too late, and "struct frobar" is now in
> >> c-found-types, with all the ensuing consequences.

> > I don't think this happens for struct/union/enum/class/... tags anymore.
> > But I think it still does for other types of types.  Mostly having a
> > mis-typed identifier in c-found-types shouldn't annoy too much, unless
> > it's some other sort of identifier in the code.

> So if the typo turns from:

>   register struct frobar *...

> to

>   register frobar *...

> there will be a problem?  That's not very reassuring.

There won't usually be a problem.  There will be a superfluous entry
"frobar" in c-found-types, but that won't affect anything unless there's
an actual identifier frobar in the buffer.

> > There were loud complaints around 18 months ago about CC Mode's
> > fontification being "random", together with pressure to fix it.  The
> > thread on emacs-devel was started by Daniel Colascione on 2021-06-03 with
> > subject line "cc-mode fontification feels random".  The current
> > compromise arose out of that thread.

> I suggest turning the compromise off by default.

There is no on and off, here.  Types need to get handled somehow.  A
great portion of all types are "found types", recognised from their
context in the program and entered into c-found-types.

> People who care about ``random'' fontification can then turn it on, or
> use the new tree-sitter modes if they can.

Failing to fontify a type is just as random as wrongly fontifying
something as a type.

> Misfontificiation is a much more serious problem than fontification
> being ommitted for unconventional-looking types!

Failing to fontify a type is also misfontification.  The consensus from
that emacs-devel thread ~18 months ago was that it is not in order to
fontify randomly.

What do you think of a facility that would allow a user to remove a
specific type from c-found-types?  It would work by putting point over
the offending identifier, and entering something like C-c C-f?

Also, are you still seeing these misfontifications in practice?  The lack
of bug reports over the last few days suggests either the bugs aren't
happening (much?) any more, or you've just got tired of submitting bug
reports.  ;-)

> > As I say, I think CC Mode has pretty much reached the end of the road as
> > far as indentation and (particularly) fontification go.  Any fix of one
> > particular problem leads to other problems springing up.  I think we must
> > look forward to the upcoming tree-sitter new modes.  I will be trying to
> > break these with CC Mode's test suite and 20 years' worth of bug reports
> > with unusual cases in them.  ;-)

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

Ah.  I actually suspect tree-sitter will be a lot more painful than most
people expect, and that CC Mode will continue to be generally used for
quite some time.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).