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