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

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

[Yikai Zhao]

I encountered this bug while testing the mps (scratch/igc) branch. I
cannot reproduce this with the current master branch.

I'm running Linux, X11, fcitx chinese input method.

Fcitx input method is popular among CJK users. When it's enabled, all
character inputs should be displayed in the "fcitx preedit box"; until a
confirmation key (e.g. space) is pressed, the composed characters should
then be inserted into the application (e.g. emacs).

Now, with the mps branch, occasinoally, some key input would NOT go to
the fcitx preedit box; instead, it goes into emacs directly. It happens
regardless of whether the fcitx preedit box is currently active. (aka,
both first-chars and non-first-chars may have this problem). If the
fcitx preedit box is active when is happens, it would remain active.

For example, when I type "niha", it starts at this:

+----------emacs buffer---------------+
| xxxxxx|                             |
|       +-----fcitx box-------+       |
|       | niha                |       |
|       | 你好 你哈 你害 ..   |       |
|       +---------------------+       |
|                                     |
+-------------------------------------+

Then I type "o", the expected behavior is:

+----------emacs buffer---------------+
| xxxxxx|                             |
|       +-----fcitx box-------+       |
|       | nihao               |       |
|       | 你好 你哈 你害 ..   |       |
|       +---------------------+       |
|                                     |
+-------------------------------------+

But instead, what I get is:

+----------emacs buffer---------------+
| xxxxxxo|                             |
|       +-----fcitx box-------+       |
|       | niha                |       |
|       | 你好 你哈 你害 ..   |       |
|       +---------------------+       |
|                                     |
+-------------------------------------+


In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.22.30, cairo version 1.15.10) of 2024-11-24 built on f2908c960c38
Repository revision: 0756b1f2f5452d715396f66d887c137776e360ca
Repository branch: scratch/igc
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Ubuntu 22.04.5 LTS

Configured using:
 'configure --prefix=/work/dist/AppDir --disable-locallisppath
 --with-native-compilation=aot --with-json --with-threads --with-sqlite3
 --with-tree-sitter --with-dbus --with-xml2 --with-modules --with-libgmp
 --with-gpm --with-lcms2 --with-mps --with-x --without-pgtk
 --without-gconf --with-x-toolkit=gtk3 --with-xft --without-tiff
 --without-imagemagick --with-gif --with-png --with-rsvg --with-webp
 --with-harfbuzz --with-cairo --with-libotf --without-m17n-flt
 --with-jpeg emacs_cv_jpeglib=/usr/lib/x86_64-linux-gnu/libjpeg.a
 CPPFLAGS=-I/work/dist/AppDir/include LDFLAGS=-L/work/dist/AppDir/lib'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LCMS2
LIBOTF LIBXML2 MODULES MPS NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG
SECCOMP SOUND SQLITE3 THREADS TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11
XDBE XIM XINPUT2 XPM GTK3 ZLIB

Important settings:
  value of $EMACSDATA: /tmp/.mount_emacsCDP179/share/emacs/31.0.50/etc
  value of $EMACSDOC: /tmp/.mount_emacsCDP179/share/emacs/31.0.50/etc
  value of $EMACSLOADPATH: /tmp/.mount_emacsCDP179/share/emacs/31.0.50/lisp
  value of $EMACSPATH:
/tmp/.mount_emacsCDP179/libexec/emacs/31.0.50/x86_64-pc-linux-gnu
  value of $LC_MONETARY: en_US.UTF-8
  value of $LC_NUMERIC: en_US.UTF-8
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=fcitx
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  evil-vimish-fold-mode: t
  vimish-fold-mode: t
  diff-hl-mode: t
  flycheck-posframe-mode: t
  flycheck-mode: t
  ligature-mode: t
  whitespace-mode: t
  electric-pair-mode: t
  hl-todo-mode: t
  dtrt-indent-mode: t
  projectile-mode: t
  tempel-abbrev-mode: t
  company-mode: t
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  hl-line-mode: t
  display-line-numbers-mode: t
  windmove-mode: t
  recentf-mode: t
  pixel-scroll-precision-mode: t
  server-mode: t
  winner-mode: t
  global-auto-revert-mode: t
  save-place-mode: t
  vertico-mode: t
  which-key-mode: t
  global-evil-visualstar-mode: t
  evil-visualstar-mode: t
  evil-snipe-override-mode: t
  evil-snipe-override-local-mode: t
  evil-owl-mode: t
  global-evil-surround-mode: t
  evil-surround-mode: t
  evil-commentary-mode: t
  evil-mode: t
  evil-local-mode: t
  override-global-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  minibuffer-regexp-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/home/yikai/.emacs.d/lib/which-key/which-key hides
/tmp/.mount_emacsCDP179/share/emacs/31.0.50/lisp/which-key
/home/yikai/.emacs.d/lib/transient/lisp/transient hides
/tmp/.mount_emacsCDP179/share/emacs/31.0.50/lisp/transient
/home/yikai/.emacs.d/lib/editorconfig/editorconfig hides
/tmp/.mount_emacsCDP179/share/emacs/31.0.50/lisp/editorconfig
/home/yikai/.emacs.d/lib/editorconfig/editorconfig-tools hides
/tmp/.mount_emacsCDP179/share/emacs/31.0.50/lisp/editorconfig-tools
/home/yikai/.emacs.d/lib/editorconfig/editorconfig-fnmatch hides
/tmp/.mount_emacsCDP179/share/emacs/31.0.50/lisp/editorconfig-fnmatch
/home/yikai/.emacs.d/lib/editorconfig/editorconfig-core hides
/tmp/.mount_emacsCDP179/share/emacs/31.0.50/lisp/editorconfig-core
/home/yikai/.emacs.d/lib/editorconfig/editorconfig-core-handle hides
/tmp/.mount_emacsCDP179/share/emacs/31.0.50/lisp/editorconfig-core-handle
/home/yikai/.emacs.d/lib/editorconfig/editorconfig-conf-mode hides
/tmp/.mount_emacsCDP179/share/emacs/31.0.50/lisp/editorconfig-conf-mode
/home/yikai/.emacs.d/lib/compat/compat hides
/tmp/.mount_emacsCDP179/share/emacs/31.0.50/lisp/emacs-lisp/compat

Features:
(shadow sort mail-extr emacsbug evil-vimish-fold vimish-fold f s
git-gutter-fringe fringe-helper git-gutter evil-collection-diff-hl
diff-hl evil-collection-log-view log-view evil-collection-vc-dir vc-dir
ewoc vc vc-dispatcher flycheck-posframe posframe flycheck-google-cpplint
evil-collection-flycheck flycheck ligature whitespace elec-pair hl-todo
dtrt-indent company-keywords company-dabbrev-code company-dabbrev
company-files projectile evil-collection-grep grep ibuf-ext
evil-collection-ibuffer ibuffer ibuffer-loaddefs url-queue
pr-review-search tempel company-abbrev company-emoji company-emoji-list
company-capf company bazel evil-collection-xref xref which-func
testcover evil-collection-edebug edebug evil-collection-debug debug
backtrace evil-collection-python python treesit project
evil-collection-imenu imenu ffap cc-mode cc-fonts cc-guess cc-menus
cc-cmds textsec uni-scripts idna-mapping ucs-normalize uni-confusable
textsec-check pr-review pr-review-render shr pixel-fill kinsoku url-file
svg dom pr-review-action magit-diff smerge-mode diff
evil-collection-diff-mode diff-mode track-changes git-commit
evil-collection-log-edit log-edit message sendmail yank-media
evil-collection-dired dired dired-loaddefs rfc822 mml mml-sec
evil-collection-epa epa derived epg rfc6068 epg-config gnus-util
mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader pcvs-util
add-log magit-core magit-autorevert magit-margin magit-transient
magit-process with-editor magit-mode transient browse-url benchmark
magit-git magit-base crm pr-review-input evil-collection-markdown-mode
markdown-mode evil-collection-outline noutline outline mule-util pulse
mail-utils network-stream url-cache hl-line display-line-numbers
pr-review-notification pr-review-listview pr-review-api ghub-graphql
treepy gsexp ghub url-http mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr url-gw nsm url-auth url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf url-util
mailcap let-alist gnutls puny pr-review-common
evil-collection-magit-section magit-section dash windmove cl-print igc
vertico-directory orderless recentf tree-widget wid-edit
evil-collection-consult consult cursor-sensor help-fns time pixel-scroll
cua-base auth-source-pass url-parse url-vars server fcitx dbus xml
winner evil-collection-vterm vterm evil-collection-bookmark bookmark pp
face-remap evil-collection-compile compile text-property-search
evil-collection-term term disp-table ehelp find-func vterm-module
term/xterm xterm cc-styles cc-align cc-engine cc-vars cc-defs
google-c-style midnight autorevert filenotify saveplace tramp-cache
time-stamp tramp-sh tramp trampver tramp-integration files-x
tramp-message tramp-compat xdg shell pcomplete evil-collection-comint
comint ansi-osc parse-time iso8601 time-date auth-source eieio
eieio-core password-cache json map ansi-color tramp-loaddefs cus-load
evil-collection-vertico vertico compat solarized-light-theme
solarized-theme solarized solarized-faces color
evil-collection-which-key which-key fringe-scale switch-buffer-functions
evil-visualstar evil-snipe evil-owl format-spec evil-surround
evil-commentary evil-commentary-integration
evil-collection-tabulated-list evil-collection-tab-bar
evil-collection-simple evil-collection-replace
evil-collection-process-menu evil-collection-kmacro evil-collection-info
evil-collection-indent evil-collection-help evil-collection-elisp-mode
evil-collection-eldoc evil-collection-buff-menu evil-collection annalist
evil evil-integration evil-maps evil-commands evil-digraphs reveal
evil-jumps evil-command-window evil-types evil-search evil-ex
evil-macros evil-repeat evil-states evil-core advice evil-common
thingatpt rect evil-vars ring edmacro kmacro byte-opt delight comp-run
use-package use-package-ensure use-package-delight use-package-diminish
use-package-bind-key bind-key easy-mmode use-package-core
yaml-mode-autoloads xonsh-mode-autoloads with-editor-autoloads
which-key-autoloads wgrep-autoloads vterm-autoloads vimrc-mode-autoloads
vimish-fold-autoloads vertico-autoloads treesit-auto-autoloads
treepy-autoloads transient-autoloads tempel-autoloads
switch-buffer-functions-autoloads suggest-autoloads sudo-edit-autoloads
spinner-autoloads solarized-theme-autoloads s-autoloads
rust-mode-autoloads rg-autoloads rainbow-mode-autoloads pydoc-autoloads
protobuf-mode-autoloads projectile-autoloads pr-review-autoloads
posframe-autoloads popup-autoloads pkg-info-autoloads php-mode-autoloads
package-lint-autoloads org2elcomment-autoloads org-tree-slide-autoloads
orderless-autoloads markdown-mode-autoloads magit-autoloads lv-autoloads
lua-mode-autoloads lsp-pyright-autoloads lsp-mode-autoloads
lsp-haskell-autoloads loop-autoloads llama-autoloads ligature-autoloads
kotlin-mode-autoloads just-mode-autoloads jsonnet-mode-autoloads
jinx-autoloads jinja2-mode-autoloads ht-autoloads hl-todo-autoloads
haskell-mode-autoloads groovy-mode-autoloads gptel-autoloads
goto-chg-autoloads google-c-style-autoloads go-mode-autoloads
gn-mode-autoloads git-link-autoloads git-gutter-fringe-autoloads
git-gutter-autoloads ghub-autoloads fringe-helper-autoloads
flycheck-posframe-autoloads flycheck-package-autoloads
flycheck-google-cpplint-autoloads flycheck-autoloads fish-mode-autoloads
fcitx-autoloads f-autoloads explain-pause-mode-autoloads
expand-region-autoloads exec-path-from-shell-autoloads
evil-visualstar-autoloads evil-vimish-fold-autoloads
evil-surround-autoloads evil-snipe-autoloads evil-owl-autoloads
evil-commentary-autoloads evil-collection-autoloads evil-autoloads
epl-autoloads epkg-autoloads embark-autoloads emacsql-autoloads
emacs-fringe-scale-autoloads editorconfig-autoloads
ebuild-mode-autoloads dumb-jump-autoloads dtrt-indent-autoloads
dockerfile-mode-autoloads diff-hl-autoloads devdocs-browser-autoloads
delight-autoloads dash-autoloads cuda-mode-autoloads copilot-autoloads
consult-flycheck-autoloads consult-autoloads compat-autoloads
company-emoji-autoloads company-autoloads codeium-autoloads cl-macs
cmake-mode-autoloads closql-autoloads bpftrace-mode-autoloads
borg-autoloads bazel-autoloads avy-autoloads annalist-autoloads
add-node-modules-path-autoloads borg loaddefs-gen generate-lisp-file
lisp-mnt radix-tree pcase info comp cl-seq comp-cstr cl-extra help-mode
comp-common warnings icons subr-x rx gv cl-loaddefs cl-lib bytecomp
byte-compile rmc iso-transl tooltip cconv eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd touch-screen tool-bar dnd fontset image regexp-opt
fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode
register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting cairo gtk x-toolkit xinput2 x multi-tty move-toolbar
make-network-process native-compile mps emacs)

Memory information:
((conses 24 0 0) (symbols 56 0 0) (strings 40 0 0) (string-bytes 1 0)
 (vectors 24 0) (vector-slots 8 0 0) (floats 24 0 0)
 (intervals 64 0 0) (buffers 1000 0))

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

[Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Thursday, November 28th, 2024 at 13:18, Yikai Zhao <yikai@z1k.dev> wrote:
> I encountered this bug while testing the mps (scratch/igc) branch. I
> cannot reproduce this with the current master branch.

Can you reproduce it on the scratch/igc branch, but compiled without mps support?

That might help us narow it down to the MPS code or some unrelated change on that branch.

Pip

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

[Yikai Zhao]

I can confirm that the issue does not happen on the scratch/igc branch
without mps support
(or at least much less frequent)

On Thu, Nov 28, 2024 at 9:33 PM Pip Cet <pipcet@protonmail.com> wrote:
>
> On Thursday, November 28th, 2024 at 13:18, Yikai Zhao <yikai@z1k.dev> wrote:
> > I encountered this bug while testing the mps (scratch/igc) branch. I
> > cannot reproduce this with the current master branch.
>
> Can you reproduce it on the scratch/igc branch, but compiled without mps support?
>
> That might help us narow it down to the MPS code or some unrelated change on that branch.
>
> Pip

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

[Gerd Möllmann]

Yikai Zhao <yikai@z1k.dev> writes:

> I can confirm that the issue does not happen on the scratch/igc branch
> without mps support
> (or at least much less frequent)
>
> On Thu, Nov 28, 2024 at 9:33 PM Pip Cet <pipcet@protonmail.com> wrote:
>>
>> On Thursday, November 28th, 2024 at 13:18, Yikai Zhao <yikai@z1k.dev> wrote:
>> > I encountered this bug while testing the mps (scratch/igc) branch. I
>> > cannot reproduce this with the current master branch.
>>
>> Can you reproduce it on the scratch/igc branch, but compiled without mps support?
>>
>> That might help us narow it down to the MPS code or some unrelated change on that branch.
>>
>> Pip

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

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

[Gerd Möllmann]

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

Wanted to get Helmut onboard, in case he's interested, but forgot to add
him in CC. Now he is.

> Yikai Zhao <yikai@z1k.dev> writes:
>
>> I can confirm that the issue does not happen on the scratch/igc branch
>> without mps support
>> (or at least much less frequent)
>>
>> On Thu, Nov 28, 2024 at 9:33 PM Pip Cet <pipcet@protonmail.com> wrote:
>>>
>>> On Thursday, November 28th, 2024 at 13:18, Yikai Zhao <yikai@z1k.dev> wrote:
>>> > I encountered this bug while testing the mps (scratch/igc) branch. I
>>> > cannot reproduce this with the current master branch.
>>>
>>> Can you reproduce it on the scratch/igc branch, but compiled without mps support?
>>>
>>> That might help us narow it down to the MPS code or some unrelated change on that branch.
>>>
>>> Pip
>
> 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.)

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

[Helmut Eller]

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.

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

[Gerd Möllmann]

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.

What made me suspicious is that we have this in fix_frame:

	Lisp_Object *nle = &FRAME_DISPLAY_INFO (f)->name_list_element;
	IGC_FIX12_OBJ (ss, nle);

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

[Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]

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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0002-fcitx.patch --]
[-- Type: text/x-patch; name=0002-fcitx.patch, Size: 1923 bytes --]

diff --git a/src/xterm.c b/src/xterm.c
index ebcd3a786e2..066d3828bcf 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -6914,6 +6914,7 @@ x_display_info_for_display (Display *dpy)
     if (dpyinfo->display == dpy)
       return dpyinfo;
 
+  fprintf(stderr, "couldn't find display info for %p\n", dpy);
   return 0;
 }
 
@@ -13027,6 +13028,7 @@ x_dnd_begin_drag_and_drop (struct frame *f, Time time, Atom xaction,
       event_display
 	= x_display_info_for_display (next_event.xany.display);
 
+      fprintf(stderr, "event_display %p\n", event_display);
       if (event_display)
 	{
 #ifdef HAVE_X_I18N
@@ -17913,7 +17915,11 @@ x_filter_event (struct x_display_info *dpyinfo, XEvent *event)
       && !dpyinfo->prefer_native_input)
     {
 #endif
-      return XFilterEvent (event, f1 ? FRAME_X_WINDOW (f1) : None);
+      bool result;
+      result = XFilterEvent (event, f1 ? FRAME_X_WINDOW (f1) : None);
+      fprintf(stderr, "result %d (not GTK) for event %d, frame %p dpyinfo %p\n", result, event->type,
+	      f1, dpyinfo);
+      return result;
 #ifdef USE_GTK
     }
   else if (f1 && (event->type == KeyPress
@@ -17941,9 +17947,13 @@ x_filter_event (struct x_display_info *dpyinfo, XEvent *event)
 	   exercise the wire to make pselect return.  */
 	XNoOp (FRAME_X_DISPLAY (f1));
 
+      fprintf(stderr, "result %d for event %d, frame %p dpyinfo %p\n", result, event->type,
+	      f1, dpyinfo);
       return result;
     }
 
+  fprintf(stderr, "result 0 (no frame) for event %d, frame %p dpyinfo %p\n", event->type,
+	  f1, dpyinfo);
   return 0;
 #endif
 }
@@ -17965,6 +17975,7 @@ event_handler_gdk (GdkXEvent *gxev, GdkEvent *ev, gpointer data)
 
       dpyinfo = x_display_info_for_display (xev->xany.display);
 
+      fprintf(stderr, "dpyinfo %p\n", dpyinfo);
 #ifdef HAVE_X_I18N
       /* Filter events for the current X input method.
          GTK calls XFilterEvent but not for key press and release,

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

[Gerd Möllmann]

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.

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

[Gerd Möllmann]

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

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

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

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

[Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

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

It's this code in gtkutil.h:

#ifdef HAVE_MPS
INLINE gpointer
glib_user_data (void *o)
{
  gpointer p = igc_xzalloc_ambig (sizeof (o));
  memcpy (p, &o, sizeof (o));
  return p;
}

INLINE void *
get_glib_user_data (gpointer p)
{
  return *(void **)p;
}
#else
INLINE gpointer
glib_user_data (void *o)
{
  return (gpointer)o;
}

INLINE void *
get_glib_user_data (gpointer p)
{
  return (void *)p;
}
#endif

Does that look correct to you?

My understanding is that the GTK input method code is only used if
x_gtk_use_native_input is true (which we'll have to wait for the OP to
confirm or deny), but xg_create_frame_widgets always calls
gtk_im_multicontext_new, so the problem might be in the GTK code...

Pip

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

[Gerd Möllmann]

Pip Cet <pipcet@protonmail.com> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> 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.
>
> It's this code in gtkutil.h:
>
> #ifdef HAVE_MPS
> INLINE gpointer
> glib_user_data (void *o)
> {
>   gpointer p = igc_xzalloc_ambig (sizeof (o));
>   memcpy (p, &o, sizeof (o));
>   return p;
> }
>
> INLINE void *
> get_glib_user_data (gpointer p)
> {
>   return *(void **)p;
> }
> #else
> INLINE gpointer
> glib_user_data (void *o)
> {
>   return (gpointer)o;
> }
>
> INLINE void *
> get_glib_user_data (gpointer p)
> {
>   return (void *)p;
> }
> #endif
>
> Does that look correct to you?

Yes, kt does.

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

[Yikai Zhao]

On Sun, Dec 1, 2024 at 6:08 PM Pip Cet <pipcet@protonmail.com> wrote:
>
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
> > 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.
>
> It's this code in gtkutil.h:
>
> #ifdef HAVE_MPS
> INLINE gpointer
> glib_user_data (void *o)
> {
>   gpointer p = igc_xzalloc_ambig (sizeof (o));
>   memcpy (p, &o, sizeof (o));
>   return p;
> }
>
> INLINE void *
> get_glib_user_data (gpointer p)
> {
>   return *(void **)p;
> }
> #else
> INLINE gpointer
> glib_user_data (void *o)
> {
>   return (gpointer)o;
> }
>
> INLINE void *
> get_glib_user_data (gpointer p)
> {
>   return (void *)p;
> }
> #endif
>
> Does that look correct to you?
>
> My understanding is that the GTK input method code is only used if
> x_gtk_use_native_input is true (which we'll have to wait for the OP to
> confirm or deny),

`x-gtk-use-native-input` is nil here, if that's what you are asking.

> but xg_create_frame_widgets always calls
> gtk_im_multicontext_new, so the problem might be in the GTK code...
>
> Pip
>

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

[Yikai Zhao]

Setting `x-gtk-use-native-input` to `t` seems to fix the issue for me!

On Mon, Dec 2, 2024 at 4:58 PM Yikai Zhao <yikai@z1k.dev> wrote:
>
> On Sun, Dec 1, 2024 at 6:08 PM Pip Cet <pipcet@protonmail.com> wrote:
> >
> > Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> >
> > > 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.
> >
> > It's this code in gtkutil.h:
> >
> > #ifdef HAVE_MPS
> > INLINE gpointer
> > glib_user_data (void *o)
> > {
> >   gpointer p = igc_xzalloc_ambig (sizeof (o));
> >   memcpy (p, &o, sizeof (o));
> >   return p;
> > }
> >
> > INLINE void *
> > get_glib_user_data (gpointer p)
> > {
> >   return *(void **)p;
> > }
> > #else
> > INLINE gpointer
> > glib_user_data (void *o)
> > {
> >   return (gpointer)o;
> > }
> >
> > INLINE void *
> > get_glib_user_data (gpointer p)
> > {
> >   return (void *)p;
> > }
> > #endif
> >
> > Does that look correct to you?
> >
> > My understanding is that the GTK input method code is only used if
> > x_gtk_use_native_input is true (which we'll have to wait for the OP to
> > confirm or deny),
>
> `x-gtk-use-native-input` is nil here, if that's what you are asking.
>
> > but xg_create_frame_widgets always calls
> > gtk_im_multicontext_new, so the problem might be in the GTK code...
> >
> > Pip
> >

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

[Yikai Zhao]

Hello Pip,

I have reproduced the issue with your patch, here's the relevant log:

(Lines starting with '#' are my comments)

dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0

# Pressed first character here. It goes to fcitx normally.

result 1 (not GTK) for event 2, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
result 1 (not GTK) for event 3, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
result 0 (not GTK) for event 3, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0

# Pressed second character here. It goes to fcitx normally.

result 1 (not GTK) for event 2, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
result 1 (not GTK) for event 3, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0

# Pressed third character here. It goes to fcitx normally.

result 1 (not GTK) for event 2, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0

# BUG REPRODUCED HERE: Pressed fourth character here. It does not go
to fcitx. It goes to emacs instead.

result 0 (not GTK) for event 2, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
result 1 (not GTK) for event 3, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
result 0 (not GTK) for event 3, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
result 1 (not GTK) for event 3, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
result 0 (not GTK) for event 3, frame 0x7f37b4f600e8 dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0
dpyinfo 0x55c17572d8c0


Please let me know if there's any other info I can provide.

Thanks!


On Sun, Dec 1, 2024 at 12:37 AM Pip Cet <pipcet@protonmail.com> wrote:
>
> 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

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

[Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors]

"Yikai Zhao" <yikai@z1k.dev> writes:

> I have reproduced the issue with your patch, here's the relevant log:

Thank you! So it seems we call XFilterEvent correctly but it incorrectly
indicates that the keypress (event 2) should be handled by Emacs rather
than the input method. That's rather puzzling, particularly since
subsequent calls to XFilterEvent return 1, indicating that the key
release is handled by the input method.

I'm pretty much stumped at this point. It might be a timing difference
between the MPS and non-MPS builds, but I think it's more likely to be
a bug in our MPS code.

> Please let me know if there's any other info I can provide.

Well, you already tried setting x-gtk-use-native-input to t :-)

One thing you could try is to run a full x11trace of the Emacs session
and see whether anything unusual is in there. But that's not guaranteed
to yield any results.

Pip

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

[Eli Zaretskii]

> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
>  Helmut Eller <eller.helmut@gmail.com>, 74590@debbugs.gnu.org
> Date: Mon, 02 Dec 2024 16:26:50 +0000
> From:  Pip Cet via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> "Yikai Zhao" <yikai@z1k.dev> writes:
> 
> > I have reproduced the issue with your patch, here's the relevant log:
> 
> Thank you! So it seems we call XFilterEvent correctly but it incorrectly
> indicates that the keypress (event 2) should be handled by Emacs rather
> than the input method. That's rather puzzling, particularly since
> subsequent calls to XFilterEvent return 1, indicating that the key
> release is handled by the input method.
> 
> I'm pretty much stumped at this point. It might be a timing difference
> between the MPS and non-MPS builds, but I think it's more likely to be
> a bug in our MPS code.
> 
> > Please let me know if there's any other info I can provide.
> 
> Well, you already tried setting x-gtk-use-native-input to t :-)
> 
> One thing you could try is to run a full x11trace of the Emacs session
> and see whether anything unusual is in there. But that's not guaranteed
> to yield any results.

Maybe Po Lu (CC'ed) could have some additional ideas or comments.

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

[Yikai Zhao]

Here attached the relevant output of "xscope".

t=116.64 is approximately the timestamp of a correct keypress (that
goes to fcitx);
t=116.83 is approximately the timestamp of an incorrect keypress (that
goes to emacs).

I just realized that you mentioned the x11trace tool. I will also try
to reproduce with x11trace later.

---

116.64:                      120 bytes <-- X11 Server 3 (pid 3359 Xorg)
                     ..............EVENT: GenericEvent
                               extension: XInputExtension
                              event type: 0002
                                    data: (27)
116.64: Client 3 -->  140 bytes
     ............REQUEST: ChangeProperty
                    mode: Replace
                  window: WIN 06e000b4
                property: <_NET_WM_USER_TIME>
                    type: <CARDINAL>
                  format: 20
                    data: 4b367e4c
     ............REQUEST: ChangeProperty
                    mode: Append
                  window: WIN 0020015a
                property: <_client10>
                    type: <STRING>
                  format: 08
                    data:
"<^@^J^@`^@{^@^@^@^@^@^B6]\254L~6K\373^A^@^@\265^@\340^F^@^@^@^@\200^F^H^B,^Bb^A^@^@^A^@"
     ............REQUEST: SendEvent
               propagate: False
             destination: WIN 0020015a
              event-mask: 0
                   event:                      ..............EVENT:
ClientMessage
                                  format: 20
                                  window: WIN 0020015a
                                    type: <_XIM_PROTOCOL>
                                    data: 2c 00 00 00 ec 02

116.64:                       32 bytes <-- X11 Server 3 (pid 3359 Xorg)
                     ..............EVENT: PropertyNotify
                                  window: WIN 06e000b4
                                    atom: <_NET_WM_USER_TIME>
                                    time: TIM 4b367e51
                                   state: NewValue
116.70:                      120 bytes <-- X11 Server 3 (pid 3359 Xorg)
                     ..............EVENT: GenericEvent
                               extension: XInputExtension
                              event type: 0003
                                    data: (27)
116.71: Client 3 -->   20 bytes
     ............REQUEST: InternAtom
          only-if-exists: False
                    name: "_client11"
116.71:                       32 bytes <-- X11 Server 3 (pid 3359 Xorg)
                     ..............REPLY: InternAtom
                                    atom: <_client11>
116.71: Client 3 -->  112 bytes
     ............REQUEST: ChangeProperty
                    mode: Append
                  window: WIN 0020015a
                property: <_client11>
                    type: <STRING>
                  format: 08
                    data:
"<^@^J^@`^@{^@^@^@^@^@^C6`\254\221~6K\373^A^@^@\265^@\340^F^@^@^@^@\200^F^H^B,^Bb^A^@^@^A^@"
     ............REQUEST: SendEvent
               propagate: False
             destination: WIN 0020015a
              event-mask: 0
                   event:                      ..............EVENT:
ClientMessage
                                  format: 20
                                  window: WIN 0020015a
                                    type: <_XIM_PROTOCOL>
                                    data: 2c 00 00 00 ed 02

116.71:                       32 bytes <-- X11 Server 3 (pid 3359 Xorg)
                     ..............EVENT: ClientMessage
                                  source: SendEvent
                                  format: 20
                                  window: WIN 06e0001c
                                    type: <_XIM_PROTOCOL>
                                    data: 2c 00 00 00 ed fb
116.71: Client 3 -->   24 bytes
     ............REQUEST: GetProperty
                  delete: True
                  window: WIN 06e0001c
                property: ATM 0000fbed
                    type: AnyPropertyType
             long-offset: 00000000
116.71:                       76 bytes <-- X11 Server 3 (pid 3359 Xorg)
                     ..............REPLY: GetProperty
                                  format: 08
                                    type: <STRING>
                             bytes-after: 00000000
                                   value:
"<^@^J^@`^@{^@^A^@^@^@^C6`\254\221~6K\373^A^@^@\265^@\340^F^@^@^@^@^@^@^@^@,^Bb^A^@^@^@^@"
116.83:                      120 bytes <-- X11 Server 3 (pid 3359 Xorg)
                     ..............EVENT: GenericEvent
                               extension: XInputExtension
                              event type: 0002
                                    data: (27)
116.83: Client 3 -->  164 bytes
     ............REQUEST: ChangeProperty
                    mode: Replace
                  window: WIN 06e000b4
                property: <_NET_WM_USER_TIME>
                    type: <CARDINAL>
                  format: 20
                    data: 4b367f10
     ............REQUEST: SendEvent
               propagate: False
             destination: WIN 0020015a
              event-mask: 0
                   event:                      ..............EVENT:
ClientMessage
                                  format: 08
                                  window: WIN 0020015a
                                    type: <_XIM_PROTOCOL>
                                    data: 3e 00 01 00 60 00

     ............REQUEST: ChangeProperty
                    mode: Append
                  window: WIN 0020015a
                property: <_client12>
                    type: <STRING>
                  format: 08
                    data: "6^@^E^@`^@{^@^L^@^@^@^F^@^H^@^P^@^D^@,^@\256^A"
     ............REQUEST: SendEvent
               propagate: False
             destination: WIN 0020015a
              event-mask: 0
                   event:                      ..............EVENT:
ClientMessage
                                  format: 20
                                  window: WIN 0020015a
                                    type: <_XIM_PROTOCOL>
                                    data: 18 00 00 00 ee 02

116.83:                       32 bytes <-- X11 Server 3 (pid 3359 Xorg)
                     ..............EVENT: PropertyNotify
                                  window: WIN 06e000b4
                                    atom: <_NET_WM_USER_TIME>
                                    time: TIM 4b367f10
                                   state: NewValue
116.83:                       32 bytes <-- X11 Server 3 (pid 3359 Xorg)
                     ..............EVENT: ClientMessage
                                  source: SendEvent
                                  format: 08
                                  window: WIN 06e0001c
                                    type: <_XIM_PROTOCOL>
                                    data: 37 00 01 00 60 00
116.83: Client 3 -->   92 bytes
     ............REQUEST: ChangeProperty
                    mode: Append
                  window: WIN 0020015a
                property: <_client13>
                    type: <STRING>
                  format: 08
                    data: "6^@^E^@`^@{^@^L^@^@^@^F^@^H^@^P^@^D^@,^@\256^A"
     ............REQUEST: SendEvent
               propagate: False
             destination: WIN 0020015a
              event-mask: 0
                   event:                      ..............EVENT:
ClientMessage
                                  format: 20
                                  window: WIN 0020015a
                                    type: <_XIM_PROTOCOL>
                                    data: 18 00 00 00 ef 02

116.83:                       32 bytes <-- X11 Server 3 (pid 3359 Xorg)
                     ..............EVENT: ClientMessage
                                  source: SendEvent
                                  format: 08
                                  window: WIN 06e0001c
                                    type: <_XIM_PROTOCOL>
                                    data: 37 00 01 00 60 00
116.83: Client 3 -->  324 bytes
     ............REQUEST: SetClipRectangles
                ordering: UnSorted
                      gc: GXC 06e006c5
           clip-x-origin: 0
           clip-y-origin: 0
              rectangles: (1)
     ............REQUEST: RenderRequest
           RENDERREQUEST: RenderFillRectangles
                      op: Src
                    dest: PICTURE 06e000fc
                   color: COLOR r:fdfd g:f6f6 b:e3e3 a:ffff
              rectangles: (1)
     ............REQUEST: RenderRequest
           RENDERREQUEST: RenderCompositeGlyphs8
                      op: Over
                  source: PICTURE 06e006cc
                    dest: PICTURE 06e000fc
             mask format: None
                glyphset: GLYPHSET 06e00104
                   x-src: 44
                   y-src: 424
                   items:
                 delta x: 44
                 delta y: 424
     glyph item 8 string: "I"
     ............REQUEST: ChangeGC
                      gc: GXC 06e006c5
              value-mask: clip-mask
              value-list:
                   clip-mask: None
     ............REQUEST: SetClipRectangles
                ordering: UnSorted
                      gc: GXC 06e006c5
           clip-x-origin: 0
           clip-y-origin: 0
              rectangles: (1)
     ............REQUEST: RenderRequest
           RENDERREQUEST: RenderFillRectangles
                      op: Src
                    dest: PICTURE 06e000fc
                   color: COLOR r:fdfd g:f6f6 b:e3e3 a:ffff
              rectangles: (1)
     ............REQUEST: ChangeGC
                      gc: GXC 06e006c5
              value-mask: clip-mask
              value-list:
                   clip-mask: None
     ............REQUEST: SetClipRectangles
                ordering: UnSorted
                      gc: GXC 06e0012f
           clip-x-origin: 0
           clip-y-origin: 0
              rectangles: (1)
     ............REQUEST: RenderRequest
           RENDERREQUEST: RenderFillRectangles
                      op: Src
                    dest: PICTURE 06e000fc
                   color: COLOR r:6565 g:7b7b b:8383 a:ffff
              rectangles: (1)
     ............REQUEST: ChangeGC
                      gc: GXC 06e0012f
              value-mask: clip-mask
              value-list:
                   clip-mask: None
     ............REQUEST: ChangeProperty
                    mode: Append
                  window: WIN 0020015a
                property: <_client14>
                    type: <STRING>
                  format: 08
                    data: "6^@^E^@`^@{^@^L^@^@^@^F^@^H^@^P^@^D^@5^@\256^A"
     ............REQUEST: SendEvent
               propagate: False
             destination: WIN 0020015a
              event-mask: 0
                   event:                      ..............EVENT:
ClientMessage
                                  format: 20
                                  window: WIN 0020015a
                                    type: <_XIM_PROTOCOL>
                                    data: 18 00 00 00 f3 02

116.84:                       32 bytes <-- X11 Server 3 (pid 3359 Xorg)
                     ..............EVENT: ClientMessage
                                  source: SendEvent
                                  format: 08
                                  window: WIN 06e0001c
                                    type: <_XIM_PROTOCOL>
                                    data: 37 00 01 00 60 00
116.84: Client 3 -->   16 bytes
     ............REQUEST: DOUBLE-BUFFER-Request
            minor opcode: 03
                    data: (3)
116.90:                      120 bytes <-- X11 Server 3 (pid 3359 Xorg)
                     ..............EVENT: GenericEvent
                               extension: XInputExtension
                              event type: 0003
                                    data: (27)
116.90: Client 3 -->  112 bytes
     ............REQUEST: ChangeProperty
                    mode: Append
                  window: WIN 0020015a
                property: <_client15>
                    type: <STRING>
                  format: 08
                    data:
"<^@^J^@`^@{^@^@^@^@^@^C^Zw\254Q<del>6K\373^A^@^@\265^@\340^F^@^@^@^@\200^F^H^B,^Bb^A^@^@^A^@"
     ............REQUEST: SendEvent
               propagate: False
             destination: WIN 0020015a
              event-mask: 0
                   event:                      ..............EVENT:
ClientMessage
                                  format: 20
                                  window: WIN 0020015a
                                    type: <_XIM_PROTOCOL>
                                    data: 2c 00 00 00 f5 02

116.90:                       32 bytes <-- X11 Server 3 (pid 3359 Xorg)
                     ..............EVENT: ClientMessage
                                  source: SendEvent
                                  format: 20
                                  window: WIN 06e0001c
                                    type: <_XIM_PROTOCOL>
                                    data: 2c 00 00 00 ee fb
116.90: Client 3 -->   24 bytes
     ............REQUEST: GetProperty
                  delete: True
                  window: WIN 06e0001c
                property: ATM 0000fbee
                    type: AnyPropertyType
             long-offset: 00000000
116.90:                       76 bytes <-- X11 Server 3 (pid 3359 Xorg)
                     ..............REPLY: GetProperty
                                  format: 08
                                    type: <STRING>
                             bytes-after: 00000000
                                   value:
"<^@^J^@`^@{^@^A^@^@^@^C^Zw\254Q<del>6K\373^A^@^@\265^@\340^F^@^@^@^@^@^@^@^@,^Bb^A^@^@^@^@"
116.90: Client 3 -->   44 bytes
     ............REQUEST: SendEvent
               propagate: False
             destination: WIN 0020015a
              event-mask: 0
                   event:                      ..............EVENT:
ClientMessage
                                  format: 08
                                  window: WIN 0020015a
                                    type: <_XIM_PROTOCOL>
                                    data: 3e 00 01 00 60 00

116.93:                      120 bytes <-- X11 Server 3 (pid 3359 Xorg)
                     ..............EVENT: GenericEvent
                               extension: XInputExtension
                              event type: 0002
                                    data: (27)
116.93: Client 3 -->  140 bytes
     ............REQUEST: ChangeProperty
                    mode: Replace
                  window: WIN 06e000b4
                property: <_NET_WM_USER_TIME>
                    type: <CARDINAL>
                  format: 20
                    data: 4b367f73
     ............REQUEST: ChangeProperty
                    mode: Append
                  window: WIN 0020015a
                property: <_client16>
                    type: <STRING>
                  format: 08
                    data:
"<^@^J^@`^@{^@^@^@^@^@^B^^{\254s<del>6K\373^A^@^@\265^@\340^F^@^@^@^@\200^F^H^B,^Bb^A^@^@^A^@"
     ............REQUEST: SendEvent
               propagate: False
             destination: WIN 0020015a
              event-mask: 0
                   event:                      ..............EVENT:
ClientMessage
                                  format: 20
                                  window: WIN 0020015a
                                    type: <_XIM_PROTOCOL>
                                    data: 2c 00 00 00 f6 02

116.93:                       32 bytes <-- X11 Server 3 (pid 3359 Xorg)
                     ..............EVENT: PropertyNotify
                                  window: WIN 06e000b4
                                    atom: <_NET_WM_USER_TIME>
                                    time: TIM 4b367f73
                                   state: NewValue

On Tue, Dec 3, 2024 at 12:26 AM Pip Cet <pipcet@protonmail.com> wrote:
>
> "Yikai Zhao" <yikai@z1k.dev> writes:
>
> > I have reproduced the issue with your patch, here's the relevant log:
>
> Thank you! So it seems we call XFilterEvent correctly but it incorrectly
> indicates that the keypress (event 2) should be handled by Emacs rather
> than the input method. That's rather puzzling, particularly since
> subsequent calls to XFilterEvent return 1, indicating that the key
> release is handled by the input method.
>
> I'm pretty much stumped at this point. It might be a timing difference
> between the MPS and non-MPS builds, but I think it's more likely to be
> a bug in our MPS code.
>
> > Please let me know if there's any other info I can provide.
>
> Well, you already tried setting x-gtk-use-native-input to t :-)
>
> One thing you could try is to run a full x11trace of the Emacs session
> and see whether anything unusual is in there. But that's not guaranteed
> to yield any results.
>
> Pip
>