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

From: Pip Cet <[email-masked]>
Date: Tue, 18 Feb 2025 18:27:25 +0000

"Yikai Zhao" <[email-masked]> writes:

> Hi,
>
> I have finished bisecting between the two versions, I have identified
> that it's this commit that lowers the frequency of the issue:
>
>   commit c425f10a30c96f45fe1ccce423851bf32b8cb8df: Make balancing
> buffer intervals optional>

> Based on the change of this commit, I can also verify that, with the
> newest version of feature/igc, when setting igc--balance-intervals to
> t, the issue can be reproduced with similar high probability as
> before.

So it is a timing issue, most likely, we just don't know what changed
precisely.  My next suggestion would be to add random delays near the
buffer_step function, in order to make the bug more likely, but it's
hard to do and I still cannot reproduce the issue you are seeing here...

> I also tried your newest patch, but the issue still happens... I
> modified your patch for a little bit to add some more debug info
> (timestamps etc.) and recorded a video reproducing the issue. I hope
> it helps. See attachments for the modified patch, the screencast video
> and the log.

Thank you!  That points to this commit by Po Lu in 2022:

8d0a2e4dce41fd811319e94e5f01e5fcf8b3c62a Fix build without X11 I18N

* src/xterm.c (event_handler_gdk):
(handle_one_xevent):
(x_draw_window_cursor):
(x_term_init): Fix build without HAVE_X_I18N.

That commit adds a call to xg_filter_key to event_handler_gdk, but only
if "current_count" is >= 0.  I have tried to read the code, but I don't
know what "current_count" is, why it's sometimes negative, and why in
the case that it is negative, we call handle_one_xevent without ever
calling xg_filter_key (x_filter_key now).  That would lead to the key
being handled, right?

>From my reading of the libx11 code, input methods won't work unless
XFilterKey is called once for each event, not just some of them.

> In the video, I typed: c e u i <space> c e u i <space> . Each "c e u
> i" should translates to "测试" by fcitx and "<space>" should confirm it.
> But note that the second "c" went straight to the emacs buffer. The
> video also shows the live log on the left side, maybe it will be
> helpful.

Thanks!  The other thing I notice is that you're using GenericEvent
events, while my setup (where I haven't been able to reproduce the bug
after my changes) doesn't seem to produce those.  That might also be
part of the issue.

No patch for now, it seems I was reproducing a different bug from the
one you were seeing :-(

Pip