From: Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: "Gerd Möllmann" <gerd.moellmann@gmail.com>
Cc: Yikai Zhao <yikai@z1k.dev>, Helmut Eller <eller.helmut@gmail.com>,
74590@debbugs.gnu.org
Subject: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box
Date: Sat, 30 Nov 2024 16:37:03 +0000 [thread overview]
Message-ID: <E17CtvpBS4E6fb6Ar1spO3oBhW-LsFu5YPgvs0YKtdDg9lpa0oDXSK5sgnX34L8GmZesdX6ATp5YhZUCjPqn62_ODorRuPBcMIjOocELw7c=@protonmail.com> (raw)
In-Reply-To: <m2mshhhtxt.fsf@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]
On Saturday, November 30th, 2024 at 10:55, Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
> Helmut Eller eller.helmut@gmail.com writes:
>
> > On Fri, Nov 29 2024, Gerd Möllmann wrote:
> >
> > > > Not sure if that is used in your build, but in x_display_info (xterm.h)
> > > > I see a number of struct frame pointers that are not fixed in fix_frame,
> > > > starting with
> > > >
> > > > struct frame *x_focus_frame;
> > > >
> > > > And if it's not that display info that is being used, I'd bet a small
> > > > amount that whatever is actually used (pgtk_display_info?) has a similar
> > > > problems.
> > > >
> > > > (Can't fix this myself, sorry, I only have macOS.)
> >
> > I think the x_display_info struct (I guess usually only one exists) is
> > allocated in x_term_init (or pgtk_term_init) with igc_xzalloc_ambig. So
> > theoretically it doesn't need to be traced.
>
>
> Then we're good, sorry for the noise.
So it turns out X input method handling is somewhat complicated!
I've tried installing fcitx, but it seems to be working the same here with and without MPS.
It would help to establish the value of x-gtk-use-native-input, since that determines whether we use the GTK or X method for communicating with fcitx.
I've attached a patch which logs some debugging info to stderr (because displaying messages using X while debugging X code is a bad idea, IME). If you could apply it and reproduce the output around a keypress that's handled incorrectly, that might help us track this down.
Pip
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0002-fcitx.patch --]
[-- Type: text/x-patch; name=0002-fcitx.patch, Size: 1923 bytes --]
diff --git a/src/xterm.c b/src/xterm.c
index ebcd3a786e2..066d3828bcf 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -6914,6 +6914,7 @@ x_display_info_for_display (Display *dpy)
if (dpyinfo->display == dpy)
return dpyinfo;
+ fprintf(stderr, "couldn't find display info for %p\n", dpy);
return 0;
}
@@ -13027,6 +13028,7 @@ x_dnd_begin_drag_and_drop (struct frame *f, Time time, Atom xaction,
event_display
= x_display_info_for_display (next_event.xany.display);
+ fprintf(stderr, "event_display %p\n", event_display);
if (event_display)
{
#ifdef HAVE_X_I18N
@@ -17913,7 +17915,11 @@ x_filter_event (struct x_display_info *dpyinfo, XEvent *event)
&& !dpyinfo->prefer_native_input)
{
#endif
- return XFilterEvent (event, f1 ? FRAME_X_WINDOW (f1) : None);
+ bool result;
+ result = XFilterEvent (event, f1 ? FRAME_X_WINDOW (f1) : None);
+ fprintf(stderr, "result %d (not GTK) for event %d, frame %p dpyinfo %p\n", result, event->type,
+ f1, dpyinfo);
+ return result;
#ifdef USE_GTK
}
else if (f1 && (event->type == KeyPress
@@ -17941,9 +17947,13 @@ x_filter_event (struct x_display_info *dpyinfo, XEvent *event)
exercise the wire to make pselect return. */
XNoOp (FRAME_X_DISPLAY (f1));
+ fprintf(stderr, "result %d for event %d, frame %p dpyinfo %p\n", result, event->type,
+ f1, dpyinfo);
return result;
}
+ fprintf(stderr, "result 0 (no frame) for event %d, frame %p dpyinfo %p\n", event->type,
+ f1, dpyinfo);
return 0;
#endif
}
@@ -17965,6 +17975,7 @@ event_handler_gdk (GdkXEvent *gxev, GdkEvent *ev, gpointer data)
dpyinfo = x_display_info_for_display (xev->xany.display);
+ fprintf(stderr, "dpyinfo %p\n", dpyinfo);
#ifdef HAVE_X_I18N
/* Filter events for the current X input method.
GTK calls XFilterEvent but not for key press and release,
next prev parent reply other threads:[~2024-11-30 16:37 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-28 13:18 bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box Yikai Zhao
2024-11-28 13:32 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-29 4:26 ` Yikai Zhao
2024-11-29 5:21 ` Gerd Möllmann
2024-11-29 5:55 ` Gerd Möllmann
2024-11-30 10:39 ` Helmut Eller
2024-11-30 10:55 ` Gerd Möllmann
2024-11-30 16:37 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2024-12-01 6:04 ` Gerd Möllmann
2024-12-01 7:33 ` Gerd Möllmann
2024-12-01 10:08 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-01 11:30 ` Gerd Möllmann
2024-12-02 8:58 ` Yikai Zhao
2024-12-02 10:06 ` Yikai Zhao
2024-12-02 8:56 ` Yikai Zhao
2024-12-02 16:26 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-02 16:51 ` Eli Zaretskii
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='E17CtvpBS4E6fb6Ar1spO3oBhW-LsFu5YPgvs0YKtdDg9lpa0oDXSK5sgnX34L8GmZesdX6ATp5YhZUCjPqn62_ODorRuPBcMIjOocELw7c=@protonmail.com' \
--to=bug-gnu-emacs@gnu.org \
--cc=74590@debbugs.gnu.org \
--cc=eller.helmut@gmail.com \
--cc=gerd.moellmann@gmail.com \
--cc=pipcet@protonmail.com \
--cc=yikai@z1k.dev \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).