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