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. 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. Bill Bill Sacks wrote on 7/29/22 2:23 PM: > Thank you very much for this quick reply and fix, Alan! Yes, from a > couple of tests, this fixes the issue I was having (and stops me from > getting distracted by constantly changing fontification while writing > a comment – thank you!). I'll let you know if I notice any remaining > issues. > > This does not fix the issue I'm seeing with fontification of variable > names in python-mode (which also appears to be an Emacs 28 > regression), but given that this fix is specific to cc-engine, the > python-mode issue is apparently different. That one seems a little > harder to reproduce, so it may take me a while to develop a simple > reproducer for it, especially since I haven't been doing much python > programming recently. However, please let me know if you would like me > to prioritize opening an issue for that one: I can do so sooner if it > would be helpful. > > Thanks again, > Bill > > Alan Mackenzie wrote on 7/29/22 11:44 AM: >> Hello, Bill and Eli. >> >> On Fri, Jul 29, 2022 at 08:56:21 +0300, Eli Zaretskii wrote: >>>> From: Bill Sacks >>>> Date: Thu, 28 Jul 2022 14:32:09 -0600 >> First of all (Bill), thanks for taking the trouble to report this bug, >> and thanks even more for cutting the test case down to the short fragment >> in your screenshots. >> >>>> Starting with Emacs 28, I have been seeing font-lock issues when >>>> editing C and C++ code. The situation where I see this the most >>>> (though I'm not sure if it's the only situation) is when I am writing >>>> a comment and currently have a space at the end of the comment line: >>>> in this situation, the fontification of a variable name or function >>>> name on the next line becomes broken until I type a non-space >>>> character to end the current line. >>>> The attached screen shots illustrate the problem: nospaces.png shows >>>> the correct fontification; space_before_var.png and >>>> space_before_function.png show that variable and function names lose >>>> their fontification when there is a space at the end of the previous >>>> comment line. Running M-x font-lock-fontify-buffer temporarily fixes >>>> the issue. >>>> The problem occurs even when using emacs -Q. I have tried the latest >>>> emacs28 pretest and the latest nightly build available from >>>> emacsformacosx (though with my customizations – NOT with emacs -Q) >>>> and those also exhibit the problem. The latest emacs27 from >>>> emacsformacosx does NOT have this issue. >> This is a coding bug in an optimisation from March 2020, where the >> complaint was that scrolling over a 2,000 line macro was slow. The fix >> neglected the possibility of spaces at the end of comment lines. >> >> Could you please apply the following patch in your Emacs-28.1, byte >> compile the file ..../lisp/progmodes/cc-engine.el, then try out the >> result on your real code. (If you want any help with the patching or >> byte compiling, feel free to send me private mail.) Then please confirm >> that the bug is fixed, or tell us how it's not fixed. Thanks! >> >> >> >> diff -r 9c649274b259 cc-engine.el >> --- a/cc-engine.el Tue Jul 26 20:08:39 2022 +0000 >> +++ b/cc-engine.el Fri Jul 29 17:25:16 2022 +0000 >> @@ -1679,9 +1679,13 @@ >> Return the result of `forward-comment' if it gets called, nil otherwise." >> `(if (not comment-end-can-be-escaped) >> (forward-comment -1) >> - (when (and (< (skip-syntax-backward " >") 0) >> - (eq (char-after) ?\n)) >> - (forward-char)) >> + (let ((dist (skip-syntax-backward " >"))) >> + (when (and >> + (< dist 0) >> + (progn >> + (skip-syntax-forward " " (- (point) dist 1)) >> + (eq (char-after) ?\n))) >> + (forward-char))) >> (cond >> ((and (eq (char-before) ?\n) >> (eq (char-before (1- (point))) ?\\)) >> >> >> >> >>> Alan, this seems to be a regression in Emacs 28, so could you please >>> look into it? >> Eli, Do I understand you want the fix in the release branch? >> >