bug#74590: 31.0.50 [scratch/igc branch]; key input sometimes skip fcitx input method preedit box

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Pip Cet <pipcet@protonmail.com> writes:

> 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

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.