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 #32 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 08:33:21 +0100

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

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

It probably isn't relevant because of this

  #ifdef HAVE_MPS
  void free_glib_user_data (gpointer data, GClosure *closure)
  {
    igc_xfree (data);
  }
  #else
  void free_glib_user_data (gpointer data, GClosure *closure)
  {
    return;
  }
  #endif

Don't know where the allocation takes place.

I should shut up, I guess :-).

Previous Next

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