Windows编程如何改善 Emacs 系统中文输入法的拼音缩放问题

zdn · 2026 年6 月 22 日 03:50

Windows上的emacs对于中文输入法来说拼音的候选字符串是非常非常小的不用我多说这个体验非常非常糟糕如图

这个想通过elisp修改是做不到的我最近尝试了一下 librime 编辑体验来说是可以的但是每次启动emacs都会加载字典第一次往往有10-20秒具体看字典的大小有时候加载完一次以后下次打开emacs会有缓存可以做到1-2秒以内打开但是这个缓存非常不稳定有时候会丢缓存第一次emacs打开以后下次打开还会重新加载整个字典我的需求是让拼音的候选缩放变大实际上用rime是杀鸡用牛刀了我会一点点Windows编程所以我就打算自己解决这是效果

aaaa

通过动态模块加载以后先获得窗口句柄然后窗口子类化获得窗口过程也就是常见的 WndProc 然后拦截到对应的ime消息巴拉巴拉具体的看我的仓库代码代码量很少

我打包好了dll进去可以直接使用如果没有编译的工具链的话

TomoeMami · 2026 年6 月 22 日 04:07

根据我的使用体验来说，liberime并不需要每次加载字典。如果方案没有变动，甚至不需要重复deploy。

我看了下你之前的回帖，卡顿可能是打开了 (liberime-auto-build t) 的问题？毕竟引用的目标在src文件夹中。实际上liberime有编译好的DLL，你可以放在某个地方然后直接设置 liberime-module-file 引用之。

zdn · 2026 年6 月 22 日 07:07

以后尝试了我目前对于我这个实现方案特别满意了 c++那边通过窗口消息来拿消息 elisp那边通过轮询来读取我感觉非常不错

ksqsf · 2026 年6 月 22 日 20:06

這個問題以前討論過，也有一個 Bug report ，如果有解决办法的话推荐直接贡献给 Emacs 上游

zdn · 2026 年6 月 23 日 00:32

我看了一下这个bug请求以我来说的话我感觉这个东西很难修我的Windows经验不足以支撑我完成这个bug的修复我之所以能实现这个帖子里面的这个方案是因为我是直接从窗口的消息循环里面拿的数据然后通过命名管道的方式发给emacs 让emacs用overlay去绘制出来所以我做的只是简单的读数据不过我会试试的吧

TomoeMami · 2026 年6 月 23 日 02:40

没想到在这里遇见librime贡献者大佬了。

昨天在UCRT64上编译librime 1.17.0的时候有两个test不通过，就翻了下对应的commit。

刚才点进帖子看新回复，发现头像和名称都很熟悉啊。

[==========] 90 tests from 30 test suites ran. (77 ms total)
[  PASSED  ] 88 tests.
[  FAILED  ] 2 tests, listed below:
[  FAILED  ] RimeSyllabifierTest.TrimLeadingDelimiters
[  FAILED  ] RimeSyllabifierTest.TrimBothLeadingAndTrailingDelimiters

github.com/rime/librime

MSYS2的UCRT64环境中编译1.17.0，测试失败

已打开 02:27PM - 22 Jun 26 UTC

TomoeMami

bug

报错节选： ``` Start 1: rime_test 1/1 Test #1: rime_test ........................*…**Failed 0.30 sec [==========] Running 90 tests from 30 test suites. [----------] Global test environment set-up. …… [ RUN ] RimeSyllabifierTest.TrimLeadingDelimiters D:/msys64/home/riko/MINGW-packages/mingw-w64-librime/src/librime-1.17.0/test/syllabifier_test.cc:170: Failure Expected equality of these values: input.length() Which is: 3 g.interpreted_length Which is: 0 D:/msys64/home/riko/MINGW-packages/mingw-w64-librime/src/librime-1.17.0/test/syllabifier_test.cc:171: Failure Expected equality of these values: 2 g.vertices.size() Which is: 1 D:/msys64/home/riko/MINGW-packages/mingw-w64-librime/src/librime-1.17.0/test/syllabifier_test.cc:172: Failure Value of: g.vertices.end() == g.vertices.find(3) Actual: true Expected: false [ FAILED ] RimeSyllabifierTest.TrimLeadingDelimiters (4 ms) …… [ RUN ] RimeSyllabifierTest.TrimBothLeadingAndTrailingDelimiters D:/msys64/home/riko/MINGW-packages/mingw-w64-librime/src/librime-1.17.0/test/syllabifier_test.cc:204: Failure Expected equality of these values: input.length() Which is: 5 g.interpreted_length Which is: 0 D:/msys64/home/riko/MINGW-packages/mingw-w64-librime/src/librime-1.17.0/test/syllabifier_test.cc:205: Failure Expected equality of these values: 2 g.vertices.size() Which is: 1 D:/msys64/home/riko/MINGW-packages/mingw-w64-librime/src/librime-1.17.0/test/syllabifier_test.cc:206: Failure Value of: g.vertices.end() == g.vertices.find(5) Actual: true Expected: false [ FAILED ] RimeSyllabifierTest.TrimBothLeadingAndTrailingDelimiters (0 ms) [----------] 9 tests from RimeSyllabifierTest (8 ms total) …… [----------] Global test environment tear-down [==========] 90 tests from 30 test suites ran. (77 ms total) [ PASSED ] 88 tests. [ FAILED ] 2 tests, listed below: [ FAILED ] RimeSyllabifierTest.TrimLeadingDelimiters [ FAILED ] RimeSyllabifierTest.TrimBothLeadingAndTrailingDelimiters 2 FAILED TESTS YOU HAVE 1 DISABLED TEST ``` 相关测试函数：[TEST_F(RimeSyllabifierTest, TrimLeadingDelimiters) {](https://github.com/rime/librime/blob/5b5d6cca9a4202a78f15edba53715e2a0d291d6b/test/syllabifier_test.cc#L164) 因为我不懂C，在AI的指导下一番调试之后，它给出了诊断： > 输出表明，BuildSyllableGraph 在图构建阶段完全没有生成任何边，顶点只有起点 0。这很可能是因为在 UCRT64 环境下，SpellingAccessor 在 spelling_map_ 为空时的行为与测试预期不符，导致拼写插入失败。 > 原始测试中 Build(keyset) 没传 script，导致 prism 内部 spelling_map_ 保持为 nullptr。虽然 SpellingAccessor 对 null 有降级处理（直接返回 spelling_id 作为音节），但在 UCRT64 编译环境下，可能因为结构对齐、优化或未定义行为导致 while (!accessor.exhausted()) 循环内的插入逻辑异常，最终 spellings 被判为空，边被丢弃。

zdn · 2026 年6 月 23 日 05:06

我试着去修改了一下源码照着gvim的去设置我修改的是w32fns.c文件里面的 w32_wnd_proc 函数这个是Windows的事件循环窗口我找到相关的 IME 事件调用这个bug报告里面说的 ImmSetCompositionFontW 方法去设置编译成功以后去打开emacs发现输入法的拼音候选框缩放没有反应按照我的经验来说这个候选框的dpi缩放应该是要在全局开启什么api来启用的类似 com 接口的初始化api一样我完全没有接触过这个按我的经验来说 Windows上的软件 dpi的适配默认系统是不会帮你缩放的得软件自己处理 emacs既然没有处理正确的话那就让系统接管看看

设置好以后是这样会比默认的大一倍

这是默认的

让系统接管dpi设置的话会有渲染发虚的问题想像vim那样根据字体大小动态缩放拼音候选的大小得让有经验的Windows开发者和emacs维护者来解决这个问题了我是这个月刚入坑的我目前解决不了这个问题但是我感觉我这个帖子的方案是比较好的一个选择它把输入法的拼音渲染到emacs的buffer里面我感觉很好所以这对我来说想修复的动力就小了

wsug · 2026 年7 月 10 日 05:59

这个问题看大家描述，会让人以为只有windows emacs才有这个问题？，实际应该是与emacs没有关系，任何使用windows原生输入法的程序都会遇到吧，但除了emacs用户无人反馈，所以解决方案也只对emacs有效

zdn · 2026 年7 月 10 日 06:19

我用最直白最直观的话给你描述这个问题在浏览器里面输入中文浏览器会给你内联这些拼音候选你可以试试这是浏览器特别处理的。 Windows上有个经典软件叫记事本我不知道它有没有内联拼音因为背景是白色的我看不清楚不过有一点像上面那个bug报告说的一样它和gvim是能在缩放的时候根据字体大小取缩放这个拼音缩放我特地下了一个gvim测试过。这和emacs是有关系的不能算是bug但算是功能缺失。任何使用Windows原生输入法的程序会不会遇到？这个很难跟你说明白现在的主流软件是浏览器套壳浏览器会帮你处理如果是win32原生控件那也不会有这个问题因为win32的原生编辑框控件大多用的也是记事本的编辑框也不存在这个问题只有像emacs这种高度定制的文本编辑器从零开始写的需要处理大量的相关输入法事件才会有这种问题具体的实现代码文件是w32fns.c 解决方案当然是只对emacs有效我发帖子就是说的这件事情

zdn · 2026 年7 月 14 日 03:02

修复了不支持 child-frame的问题之前的代码只支持绑定一个窗口有时序问题现在可以支持child-frame的窗口了

aaa

Windows编程 如何改善 Emacs 系统中文输入法的拼音缩放问题

Windows编程如何改善 Emacs 系统中文输入法的拼音缩放问题