InputHelper_sublime 在 Sublime Text 4 上完全不可用，因其依赖已废弃的 API 和 PyGTK，且不兼容 Skia 渲染、Wayland 及沙箱机制；正确方案是通过环境变量和命令行启动使系统输入法直接接管。
InputHelper_sublime 在 Sublime Text 4 上根本不能用
这个插件是 Sublime Text 2/3 时代的产物，依赖已废弃的 sublime_plugin.WindowCommand 早期行为和 GTK 输入法桥接逻辑，在 Sublime Text 4（基于 Skia 渲染 + 新窗口系统）上会直接报错或完全无响应。你装了也看不到任何输入框弹出，ctrl+shift+u 或其他快捷键没反应，控制台里刷一堆 AttributeError: 'Window' object has no attribute 'active_view' 类似错误。
- 它不兼容 Wayland，只尝试适配 X11，而现代 Linux 发行版默认启用 Wayland
- 它硬编码调用
gtk.gdk（PyGTK），但 Sublime Text 4 内置 Python 环境不含 PyGTK，也根本不加载系统 GTK 模块 - 即使你手动装 PyGTK 并 patch 插件，也会因 Sublime 的沙箱机制被拦截
Linux 下 Sublime Text 4 输入中文的正确姿势
不是靠插件“修复”，而是绕过插件、让系统输入法直接接管编辑器窗口。关键在启动方式和环境变量——Sublime Text 本身对 IBus/Fcitx5 完全透明，只要窗口属性和环境对得上，输入法就能正常上屏。
- 必须用命令行启动：
env GTK_IM_MODULE=ibus fcitx5-remote -r && subl（Fcitx5）或env GTK_IM_MODULE=ibus ibus restart && subl（IBus） - 不要从桌面图标或启动器直接点开，那会丢失
GTK_IM_MODULE和输入法守护进程上下文 - 确认输入法已启用“在 Qt 程序中启用”（Fcitx5 设置里有这选项），因为 Sublime 是 Qt 应用
- 如果用 Sway/i3 等平铺窗口管理器，需确保
input_method协议已启用（Sway 1.9+ 默认开）
为什么改 sublime_text.desktop 文件经常失效
很多人试图修改桌面文件里的 Exec= 行加 env GTK_IM_MODULE=...，结果点了图标还是打不出中文——问题出在桌面环境（GNOME/KDE）会忽略该环境变量，或被 systemd user session 覆盖。
- GNOME 会强制重置
GTK_IM_MODULE为ibus，但不保证守护进程已就绪；你得先手动跑一次ibus restart - KDE Plasma 5.27+ 对 Qt 应用的输入法支持更稳，但仍建议用
export QT_IM_MODULE=fcitx5配合启动 - 真正可靠的方案是写个 wrapper 脚本：
#!/bin/sh\nexport GTK_IM_MODULE=fcitx5\nexport QT_IM_MODULE=fcitx5\nexport XMODIFIERS=@im=fcitx5\nexec /opt/sublime_text/sublime_text "$@"，然后用它启动
别碰 InputHelper_sublime 的 fork 或 patch 版本
GitHub 上有些标着 “ST4 compatible” 的分支，实际只是屏蔽了报错，没解决核心的输入事件转发问题。你会遇到：候选框显示在屏幕左上角、翻页失效、回车不上屏、切换中英文状态后卡死。
- 这些 patch 往往强行 hook
on_query_context或伪造window.show_input_panel，但 Sublime 的输入面板不走系统 IM，纯属文本框，无法触发中文输入法 - 有人改用
subprocess.Popen调起fctix5-diagnose，结果导致 Sublime 主进程卡住等待子进程返回 - 真要调试输入法问题，请用
fcitx5-remote -s查当前状态，或GTK_DEBUG=immodules启动看日志，别浪费时间修一个注定失败的插件
Linux 下让 Sublime 支持中文输入，本质是环境配置问题，不是插件功能问题。越想用插件“补”，越容易掉进 GTK/Qt/IM 协议层的兼容陷阱里。
