GNU bug report logs - #74590
31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box

Previous Next

Full log

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: Yikai Zhao <yikai <at> z1k.dev>, Helmut Eller <eller.helmut <at> gmail.com>,
 74590 <at> debbugs.gnu.org
Subject: Re: bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes
 skip fcitx input method preedit box
Date: Sun, 01 Dec 2024 07:04:18 +0100

Pip Cet <pipcet <at> protonmail.com> writes:

> On Saturday, November 30th, 2024 at 10:55, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
>> Helmut Eller eller.helmut <at> 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

Searching for "closure" and "user_data" turns up this in gtkutil.c:

  static void
  xg_im_context_commit (GtkIMContext *imc, gchar *str,
                        gpointer user_data)
  {
    struct frame *f = get_glib_user_data (user_data);

That's a Gtk signal handler, or whatever they are called, which
gets set, also in gtkutil.c

  g_signal_connect_data (G_OBJECT (imc), "commit",
			 G_CALLBACK (xg_im_context_commit),
			 glib_user_data (f), free_glib_user_data,
			 G_CONNECT_DEFAULT);

Looks to me like a struct frame * might be "hidden" by this in some Gtk
data structure so that it can be passed to the handler at some point.

Don't know if that's relevant.

Previous Next

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