各编辑器兼容性——VS Code / Chrome / 飞书 / 微信 / JetBrains / 终端 等场景表现
兼容性总览
光标上下文的实现依赖操作系统级的无障碍 API（macOS AX / Windows UI Automation / Android IME InputConnection）。不同编辑器对这些 API 的支持程度差异很大，直接影响光标上下文能不能正常工作。
macOS / Windows 桌面端兼容性矩阵
| 编辑器类型 | 典型应用 | 光标上下文 | 说明 |
|---|---|---|---|
| VS Code | VS Code 1.90+ | ⚠️ 需设置 | Chromium 编辑器，默认 accessibility tree 不实时，需改设置 |
| Electron 编辑器 | Cursor、Codeium、Fleet | ⚠️ 同 VS Code | 基于 Chromium，同样需要 accessibilitySupport 开启 |
| 浏览器输入框 | Chrome / Edge / Safari 文本框、富文本编辑器 | ✅ 支持良好 | Chromium/Safari 的 Text Pattern 支持完整 |
| JetBrains IDE | IntelliJ、PyCharm、WebStorm | ✅ 支持良好 | 多年来对无障碍 API 支持很好 |
| 飞书 | Feishu 桌面端、feishu.cn | ✅ 支持良好 | Electron 框架但无障碍支持较好 |
| Slack / Discord / Teams | 桌面客户端 | ✅ 支持良好 | |
| Notion 桌面客户端 | Notion Desktop | ✅ 支持良好 | Electron |
| 微信桌面客户端 | WeChat PC | ✅ 支持良好 | |
| Obsidian / Logseq | 桌面端 | ✅ 支持良好 | Electron |
| 原生 Cocoa / Win32 应用 | 系统记事本、邮件客户端 | ✅ 支持良好 | 原生控件无障碍支持最完整 |
| 终端 | Terminal.app / iTerm2 / Windows Terminal | ❌ 通常跳过 | 终端 Text Pattern 不完整，OpenLess 检测到就跳过不读 |
| 全屏独占游戏 | Minecraft、原神等 | ❌ 不适用 | 见 全屏游戏问题 |
VS Code 的设置步骤（重要）
VS Code 是 Chromium 编辑器的代表——Chromium 系编辑器的无障碍树（accessibility tree）只有在检测到活跃的辅助功能客户端时才保持光标位置同步。默认情况下，VS Code 不知道 OpenLess 在监听它，返回的光标位置可能是过期的。
设置方法
- 打开 VS Code 设置（
Cmd + ,/Ctrl + ,） - 搜索
accessibilitySupport - 把
editor.accessibilitySupport改成on（默认是auto） - 关闭 VS Code 窗口重新打开（某些版本需要 reload window）
设置前后的对比
| 设置 | 光标位置 | 光标上下文质量 |
|---|---|---|
auto（默认） | 可能返回上一次读取时的位置，不是当前真实位置 | ❌ 上下文可能错位 |
on | 返回当前真实的光标位置 | ✅ 上下文准确、有意义 |
如果光标上下文读不到会怎样
OpenLess 对光标上下文的处理策略是宁可不读也不读错：
- 如果光标控件的 Text Pattern 不支持 / 拿不到光标 range → 静默跳过，润色正常进行但没有上下文辅助
- 如果读取过程超时 → 同样跳过
- 不会报错、不会卡住、不会影响录音/转写/润色/插入的正常链路
你可能不会注意到它正在被跳过——除非你在一个应该能读到上下文的编辑器里发现同音字没被正确消歧。
Android 端兼容性
Android 端不同——OpenLess 是自定义 IME（输入法），直接从 InputConnection 读取光标前后文本。这意味着 Android 端不需要额外设置，只要 OpenLess IME 已经激活、正在某个输入框里工作，就能读光标上下文。