GNU bug report logs - #59468
29.0.50; c-ts-mode cannot fontify after macros are encountered

Previous Next

Full log

Message #50 received at 59468 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Yuan Fu <casouri <at> gmail.com>
Cc: 59468 <at> debbugs.gnu.org
Subject: Re: bug#59468: 29.0.50; c-ts-mode cannot fontify after macros are
 encountered
Date: Sat, 26 Nov 2022 10:39:52 +0800

[Message part 1 (text/plain, inline)]

Yuan Fu <casouri <at> gmail.com> writes:

> Within
>> x_dnd_begin_drag_and_drop:
>>
>> 	  if (x_dnd_movement_frame
>> 	      /* FIXME: how come this can end up with movement frames
>> 		 from other displays on GTK builds?  */
>> 	      && (FRAME_X_DISPLAY (x_dnd_movement_frame)
>> 		  == FRAME_X_DISPLAY (f))
>> 	      /* If both those variables are false, then F is no
>> 		 longer protected from deletion by Lisp code.  This
>> 		 can only happen during the final iteration of the DND
>> 		 event loop.  */
>> 	      && (x_dnd_in_progress || x_dnd_waiting_for_finish))
>> 	    {
>> 	      XSETFRAME (frame_object, x_dnd_movement_frame);
>>
>> is fontified incorrectly: the "if" is not fontified at all, and the last
>> three lines show up in the error faces.
>
> It fontifies fine here. I guess it’s fixes by some changes I made,
> although I don’t recall making changes related to if statements.

Ok, so with a fresh build from master it turns out that this still isn't
fixed.

[Screenshot from 2022-11-26 10-31-22.png (image/png, inline)]

[Message part 3 (text/plain, inline)]

>> In addition:
>>
>> Lisp_Object
>> x_dnd_begin_drag_and_drop (struct frame *f, Time time, Atom xaction,
>> 			   Lisp_Object return_frame, Atom *ask_action_list,
>> 			   const char **ask_action_names, size_t n_ask_actions,
>> 			   bool allow_current_frame, Atom *target_atoms,
>> 			   int ntargets, Lisp_Object selection_target_list,
>> 			   bool follow_tooltip)
>>
>> "Lisp_Object" and "x_dnd_begin_drag_and_drop" are not fontified at all.
>
> They are fontified fine here.

This appeared to be fixed, but it turns out that it was not actually
fixed.  "Lisp_Object" is fontified as an identifier, despite it being a
type, and "x_dnd_begin_drag_and_drop" is fontified as an identifier, not
a function name.

[Screenshot from 2022-11-26 10-33-09.png (image/png, inline)]

[Message part 5 (text/plain, inline)]

Also, the end of x_dnd_begin_drag_and_drop is now fontified as an error:

[Screenshot from 2022-11-26 10-37-33.png (image/png, attachment)]

[Message part 7 (text/plain, inline)]

>> Here:
>>
>> /* Select for input extension events used by scroll bars.  This will
>>    result in the corresponding core events not being generated for
>>    SCROLL_BAR.  */
>>
>> MAYBE_UNUSED static void
>> xi_select_scroll_bar_events (struct x_display_info *dpyinfo,
>> 			     Window scroll_bar)
>>
>> "void" is fontified in the error face.
>
> I’ll try to come up with a heuristic.

Now, MAYBE_UNUSED is fontified as a type, and void as an identifier.  :(

>> #ifdef USE_GTK
>>       /* See comment in EnterNotify above */
>>       else if (dpyinfo->last_mouse_glyph_frame)
>>         x_note_mouse_movement (dpyinfo->last_mouse_glyph_frame,
>> 			       &event->xmotion, Qnil);
>> #endif
>>
>> "else" and "dpyinfo" are fontified as types.
>
> Same.

This seemed to work for a while, but it's broken again.

[Screenshot from 2022-11-26 10-34-25.png (image/png, inline)]

[Message part 9 (text/plain, inline)]

Also, here's a new problem:

  char buf[256], buf1[400 + INT_STRLEN_BOUND (int)
		      + INT_STRLEN_BOUND (unsigned long)];

"int" and "unsigned long" are fontified as identifiers, not types!

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.