all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Yuan Fu <casouri@gmail.com>
Cc: 59468@debbugs.gnu.org
Subject: bug#59468: 29.0.50; c-ts-mode cannot fontify after macros are encountered
Date: Sat, 26 Nov 2022 10:39:52 +0800	[thread overview]
Message-ID: <877czixwuf.fsf@yahoo.com> (raw)
In-Reply-To: <D6F8BED9-4096-4956-AEB4-8EE0E8CD31B6@gmail.com> (Yuan Fu's message of "Wed, 23 Nov 2022 16:03:40 -0800")

[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]

Yuan Fu <casouri@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.


[-- Attachment #2: Screenshot from 2022-11-26 10-31-22.png --]
[-- Type: image/png, Size: 28146 bytes --]

[-- Attachment #3: Type: text/plain, Size: 715 bytes --]


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


[-- Attachment #4: Screenshot from 2022-11-26 10-33-09.png --]
[-- Type: image/png, Size: 31781 bytes --]

[-- Attachment #5: Type: text/plain, Size: 75 bytes --]


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


[-- Attachment #6: Screenshot from 2022-11-26 10-37-33.png --]
[-- Type: image/png, Size: 20518 bytes --]

[-- Attachment #7: Type: text/plain, Size: 846 bytes --]


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


[-- Attachment #8: Screenshot from 2022-11-26 10-34-25.png --]
[-- Type: image/png, Size: 25178 bytes --]

[-- Attachment #9: Type: text/plain, Size: 194 bytes --]


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!

      parent reply	other threads:[~2022-11-26  2:39 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87k03n4v0r.fsf.ref@yahoo.com>
2022-11-22  1:50 ` bug#59468: 29.0.50; c-ts-mode cannot fontify after macros are encountered Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-22 20:11   ` Yuan Fu
2022-11-23  0:41     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-23  3:30     ` Eli Zaretskii
2022-11-23  4:13       ` Yuan Fu
2022-11-23  7:36         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-23 12:53           ` Eli Zaretskii
2022-11-23 12:43         ` Eli Zaretskii
2022-11-23  1:27   ` Yuan Fu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-24  0:03   ` Yuan Fu
2022-11-24  0:36     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-24  9:19       ` Eli Zaretskii
2022-11-24 10:36         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-24 10:55           ` Eli Zaretskii
2022-11-24 12:12             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-26  2:39     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877czixwuf.fsf@yahoo.com \
    --to=bug-gnu-emacs@gnu.org \
    --cc=59468@debbugs.gnu.org \
    --cc=casouri@gmail.com \
    --cc=luangruo@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.