🏠

1. pgtk 下 Emacs 的输入法上下文 dpyinfo->im.context 通过 gtk_im_context_set_client_window 绑定在 frame 的 GTK widget window 上（ src/pgtkim.c:171-184 ）。
2. 该上下文的 focus_in/focus_out 只在 frame 级 焦点事件里切换（ src/pgtkterm.c:5869 、 5893 ）。
3. xwidget 的 WebKit widget 位于 offscreen window 中（ src/xwidget.c:423-424 ），通过 synthesize_focus_in_event （ src/xwidget.c:2110 ）合成 GDK_FOCUS_CHANGE ，让 WebKit 认为自己获得焦点。
4. WebKit 内部有自己的 GtkIMContext，获得焦点时会 gtk_im_context_focus_in 。
5. frame 内部的焦点转移 （Emacs widget ↔ WebKit widget）不触发 frame 级 focus-out，因此 Emacs 的 IM context 不会 focus_out 。

fcitx5 的焦点被 WebKit 的 IM context 抢走，Emacs 的 IM context 既没有 focus_out ，也没有在回到 Emacs buffer 后重新 focus_in ， fcitx5 侧焦点悬空，键盘事件被吞。

etc/PROBLEMS:1400 已记录此问题（commit 449bc51，2021-11），建议换 IBus 或禁用 XIM。官方未修复。官方记录的措辞与实测完全一致：「pre-edit 窗消失，Emacs frame 一打字就失去焦点」。

在任意 buffer 中依次执行：

(pgtk-use-im-context nil)
(pgtk-use-im-context t)

两步缺一不可。原因在 src/pgtkim.c:225-275 的 pgtk_im_use_context ：

• nil 分支： gtk_im_context_reset → focus_out → set_client_window(NULL) → g_object_unref ， im.context = NULL 。
• t 分支： 仅当 im.context = NULL= 时才新建 GtkIMContext，重接信号，并调用 pgtk_im_focus_in (dpyinfo->im.focused_frame) （ src/pgtkim.c:264 ），后者执行 reset / set_client_window (frame GTK widget) / focus_in 。

因此单独 t 在 context 已存在时是 空操作 ；先 nil 再 t 才触发「重建 context + 重新向 fcitx5 注册 client + focus_in」， fcitx5 看到新 client 抢回焦点。

副作用： nil 会 g_object_unref 掉 context，所以必须紧跟 t ，否则 Emacs 之后不再处理输入法。

手动两步太麻烦。按 buffer 自动切换：进入 xwidget-webkit-mode 时释放 Emacs 的 IM context（让 WebKit 独占 fcitx5），离开时重建（抢回来）。

(defun my/rebuild-pgtk-im-step1 ()
  "Release the pgtk GtkIMContext, then schedule the recreate."
  (unless (or (eq major-mode 'xwidget-webkit-mode)
              my/pgtk-im-in-webkit-p)
    (pgtk-use-im-context nil)
    (run-with-timer 0.1 nil #'my/rebuild-pgtk-im-step2)))

(defun my/rebuild-pgtk-im-step2 ()
  "Recreate the pgtk GtkIMContext after a short event-loop turn."
  (unless (or (eq major-mode 'xwidget-webkit-mode)
              my/pgtk-im-in-webkit-p)
    (pgtk-use-im-context t)))

(defun my/sync-pgtk-im-with-buffer ()
  "Give fcitx to WebKit inside xwidget-webkit buffers, reclaim elsewhere."
  (unless (minibufferp)
    (let ((in-webkit (eq major-mode 'xwidget-webkit-mode)))
      (cond
       ((and in-webkit (not my/pgtk-im-in-webkit-p))
        (pgtk-use-im-context nil)
        (setq my/pgtk-im-in-webkit-p t))
       ((and (not in-webkit) my/pgtk-im-in-webkit-p)
        (setq my/pgtk-im-in-webkit-p nil)
        (run-with-timer 0.15 nil #'my/rebuild-pgtk-im-step1))))))

(when (fboundp 'pgtk-use-im-context)
  (defvar my/pgtk-im-in-webkit-p nil
    "Non-nil while Emacs's GtkIMContext is released to WebKit.")
  (add-hook 'post-command-hook #'my/sync-pgtk-im-with-buffer))

1. run-with-idle-timer 用不得。它要等系统 idle 才计时，用户切回 Emacs 后立即打字时永远不触发。改用 run-with-timer （wall clock）。0.2 秒的 idle 版本还出现过「WebKit 里 backspace 失灵」：用户在 WebKit 停顿时系统 idle，pending 的 timer 在 WebKit 打字途中触发，抢走了键盘事件。
2. 必须排除 minibuffer 。 post-command-hook 在 minibuffer 里也会执行，此时 major-mode 是 minibuffer-mode ， in-webkit 为 nil。在 WebKit buffer 里按 M-x 、 C-x C-f 、 C-s 进入minibuffer 时，hook 会误判「已离开 WebKit」并重建 context，把WebKit 的 fcitx 抢走；从 minibuffer 回来又调 nil 。一来一回正好是「WebKit 里打字打到一半 IM context 被重建」的时序，这是backspace 失灵的 真因 （比 idle timer 那条重要）。
3. nil 和 t 要分两次 timer 调用，中间隔 0.1 秒。连续调用时 GTK 主循环没迭代，focus_out 的 X11/Wayland 事件还没处理完就 focus_in，fcitx 侧看不到焦点转移。手动 C-c I 之所以有效，是因为两次按键之间主循环自然迭代过了。