bug#58883:

Hello, Po.

On Thu, Nov 10, 2022 at 22:40:37 +0800, Po Lu wrote:
> Alan Mackenzie <[email protected]> writes:

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

> But what if there is?

OK, I see now this is a problem.  It didn't seem like it before.

> I think I am seeing that as well.  Please see the bottom of this reply
> for one actual example.

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

> But CC Mode used to work fine in Emacs 28!

> Identifiers did not turn green during the course of editing.

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

> But that didn't leave ugly, green, splotches all over my code.

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

> Right, but it doesn't result in types randomly turned green.

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

> How about an option to turn off c-found-types, at least?

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

> It's the latter.  In one file at work where this problem is particularly
> evident, a quarter of the identifiers turn green after approximately 25
> minutes of routine editing, at which point I have to re-enable CC Mode.
> That is, with Emacs off the master branch as of 4 PM this afternoon.

> I've tried to report the obvious CC Mode bugs.  I think the rest of what
> is happening is now akin to this (reconstructed through view-lossage of
> an example that happened just now):

>   register obd *obds;

>   obds = ...;

>   /* many uses of obds follow.  */

> typedef obds IIu32;
>            ^ this is the typo!!!

> after the define of `obds' is corrected to `obd', it is too late, as CC
> Mode already thinks `obds' is a type.

OK, I think I understand the problem now.  I'll try to come up with a way
of "cancelling" these "typo" found-types.

In the meantime, can I ask you to apply the attached patch?  This
reverses an "optimisation" from 2022-10-04, which fontified identifiers
as types without full analysis.  It won't solve the problem, but it might
make things more bearable for the next few days.

Also, as I've mentioned before, there's a CC Mode hack where making a
buffer change at point-min clears c-found-types.  Again not ideal, but it
might be better than nothing, for now.

-- 
Alan Mackenzie (Nuremberg, Germany).

diff -r d83cff83c20e cc-fonts.el
--- a/cc-fonts.el	Thu Nov 10 09:56:38 2022 +0000
+++ b/cc-fonts.el	Thu Nov 10 15:57:58 2022 +0000
@@ -2529,12 +2529,8 @@
 	  (widen)
 	  (goto-char (point-min))
 	  (while (re-search-forward target-re nil t)
-	    (when (and
-		   (get-text-property (match-beginning 0) 'fontified)
-		   (not (memq (c-get-char-property (match-beginning 0) 'face)
-			      c-literal-faces)))
-	      (c-put-font-lock-face (match-beginning 0) (match-end 0)
-				    font-lock-type-face))
+	    (put-text-property (match-beginning 0) (match-end 0)
+			       'fontified nil)
 	    (dolist (win-boundary window-boundaries)
 	      (when (and (< (match-beginning 0) (cdr win-boundary))
 			 (> (match-end 0) (car win-boundary))