bug#56818: 28.1; c-mode font-lock issues in Emacs 28

[Alan Mackenzie]

Hello, Bill.

On Fri, Jul 29, 2022 at 14:38:53 -0600, Bill Sacks wrote:
> Unfortunately, I still see an issue in a slightly different context. The 
> issue appears when function arguments appear on a line following the 
> function name. This one is harder to provide screen shots for, because 
> it is a bit more dynamic, but I'll try to walk through how to reproduce 
> it, referencing two attachments: The starting point is testing_start.c 
> and the end point is testing.c. If you start with testing_start.c and 
> then take some steps to get to testing.c, you will notice a few issues 
> with fontification of "somevar":

> (1) Position the cursor at the start of line 2 and hit Tab to put the 
> cursor on line 2, column 12. Type "int somevar" and notice that 
> "somevar" remains in the default face rather than being given 
> font-lock-variable-name-face.

> (2) Run M-x font-lock-fontify-buffer to make "somevar" correctly take on 
> font-lock-variable-name-face. (Interestingly, it seems fixed as soon as 
> I type "M-x" and get into the minibuffer.)

> (3) Delete then retype the "r" in "somevar", noticing that it again 
> reverts to default face

> (4) Repeat step (2) to temporarily fix the fontification

> (5) Type " // comment", noticing that "somevar" again loses its 
> fontification

> (6) Repeat step (2) to temporarily fix the fontification

> (7) Delete and retype the "t" in "comment", noticing that "somevar" 
> again loses its fontification.

> If my instructions are unclear or you cannot reproduce this, I can 
> provide a screencast where I illustrate this behavior.

Those directions are admirably clear, thanks!

> I tested briefly with Emacs 27, and it appears that the problems in (1) 
> and (3) are new issues in Emacs 28, but (5) and (7) appear in Emacs 27 
> as well.

What is happening here is a different bug, distinct from bug #56818,
with different causes.  I've opened a fresh bug for this, bug #56841,
putting you on the Cc:.

So I'm closing bug #56818 with this post, as it appears to be fixed.

[ .... ]

> Bill

-- 
Alan Mackenzie (Nuremberg, Germany).