提议：直接实现一个支持拼音匹配中文标识符的 VSCode

[lightrabbit]

参考 https://github.com/cleverdango/vscode-pinyin/issues/2#issuecomment-349509263
看起来截至目前，VSCode官方都没有也没有计划推出让插件能介入 用户输入 到 自动补全列表项(CompletionItem) 的匹配的过程。
而自己编译后再打补丁的方法也不是官方推荐的。

然而项目 CTS 给予了我一个启发，与其等官方提供API支持，或者自己写个打补丁的插件，不如直接实现一个支持这个功能的分支，在尽量保持和官方同步的情况下分发发行版，或许是一个更好的方法。

不知道各位对这个提议有何看法？欢迎一起探讨。

[nobodxbodon]

个人感觉取决于"保持和官方同步"的代价. 与#37 类似, 这种大代码量项目的官方更新量也会很大. 而且官方库的结构性修改也许还会引起"保持同步"的代价变大. 这些都是风险. 个人对vscode插件开发没有经验. 不知初步估计的(单次)工作量多大? 按照什么版本间隔进行官方同步比较合适?

[nobodxbodon]

另一个问题是发行渠道. 如果不走插件途径, 就需要自己维护整个打包过程, 以及发布平台.
个人设想另一种可能的发展方式是, 先针对一些流行语言编写插件, 实现这个功能, 在积累用户和合作者的过程中明晰需求.
然后在有足够社区支持的时候，考虑一个单一版本支持所有语言的方案。

[nobodxbodon]

@htwx 非常希望听听你的意见, 尤其在开发CTS和对应插件过程中的体会.

[lightrabbit]

@nobodxbodon 可能我先前没有说明清楚，之前做插件的流程是这样的：

1. 修改VSCode的源码，使其支持拼音匹配中文标识符
2. 对修改过的VSCode进行编译，找出和当前发行版不同的内容
3. 将有差异的部分打包到用于打补丁的插件中
4. 发布插件

而按照该issue上的流程，则只需要做第 1, 2 步。
3,4 步就不需要了.

这样的话，相比做插件的形式，“保持和官方同步”的代价反而更小。
因为做成插件的话，官方每出一个发行版，都需要做1,2步来保持同步，然后再走3,4步发布插件。
否则对于用户，安装插件就是给自己的VSCode降级……

而自己直接发布的话，节奏可以慢到只跟官方的大版本更新保持同步，来保证官方VSCode能支持的插件我们的版本也能支持就可以了。

[nobodxbodon]

@lightrabbit 嗯多谢介绍细节. 我的主要顾虑是, 如果自己发布一个定制的vsc版本, 自己需要维护整个打包过程和发布平台.
不知道vscode-pinyin能否发布在vscode自己的Extension Marketplace? 如果可以的话, 至少发布渠道不用自己打理.
另外, 上面提的另一种可能方式的主要出发点是, https://github.com/cleverdango/vscode-pinyin/issues/2#issuecomment-349550826 提到, 如果是针对某种编程语言实现这个功能, 就不用修改vscode源码(还是我理解错了?), 那么这种方式的工作量也许会更低. 虽然为支持多个编程语言需要发布多个插件, 但应该不需要跟着vscode版本升级吧?

[nobodxbodon]

@lightrabbit 确实如果要跟着小版本是不大现实。跟着大版本会好很多。不过最理想还是不用改vscode源码吧？不知是否可能做到？

[lightrabbit]

这个我说一下我所了解到的VSCode里面自动补全相关的细节：

1. 语言服务器：在这里面根据用户光标所在的上下文提供该上下文所有可用的候选项
2. VSCode的前端部分：根据语言服务器提供的所有可选项，以及用户从激活自动补全开始(例如在一个标识符后面按下.或者直接按下Ctrl+Space)到当前所输入的内容，来过滤、排序、和自动选择优先的候选项。

上面的细节是我目前为止了解到的程度，可能会有所偏差，还请指出。

然后根据上面描述的细节，如果在语言插件上面实现这个功能，则只能做到过滤的程度。
排序和优先选择这两个部分都是VSCode的前端部分实现的。在候选项多的情况下，使用起来体验可能欠佳。例如：在候选项有中文和英文的时候，VSCode的前端部分总是优先匹配英文项，即使中文的部分在拼音上看起来匹配程度应该是更高的。（这部分可以参考VSCode插件的官方例子，实现一个CompletionProvider，然后默认是提供几个固定的中文候选项和英文候选项，然后让VSCode来进行匹配。）

[lightrabbit]

@nobodxbodon 对于你在 上文 中提到的：

确实如果要跟着小版本是不大现实。跟着大版本会好很多。不过最理想还是不用改vscode源码吧？不知是否可能做到

我前段时间有再次去看了VSCode的插件API文档，并没有在里面看到有出现和CompletionItem过滤、匹配相关的api。
根据VSCode所描述的架构，扩展程序的运行环境和编辑器前端的运行环境是完全隔离的，所以也无法（这里可能不严谨，但基本上可以认为是极难）用类似注入的方式来把拼音匹配汉字的逻辑注入到前端的运行环境中。所以目前估计在不修改VSCode的源码的情况下，很难做到。

然后你在前面的回复中，还提到了：

我的主要顾虑是, 如果自己发布一个定制的vsc版本, 自己需要维护整个打包过程和发布平台.

打包的部分VSCode源码中已经实现了完整的自动化流程，基本上达到自动化集成的程度是没问题的。发布的话，直接在github上面发布release应该就可以了。

[nobodxbodon]

@lightrabbit 我还没有细看@htwx 的cts插件实现，好像功能很像。也许没有用CompletionItem相关接口？

另外，github发布毕竟是完全第三方。如果（大前提是技术上能做到不用修改vsc源码）在内置marketplace发布，受众会广一些，新用户尝试的成本，老版本更新成本也更小吧。

[nobodxbodon]

@lightrabbit 刚意识到https://github.com/program-in-chinese/CTS_Typewriting 好像是服务端, 并没有自动补全功能.
@htwx 请问cts的拼音补全插件修改了vscode的源码吗? 如果不需修改, 可否在共享代码之前介绍一下实现原理? 多谢!

[htwx]

这个 不是插件, 是服务器程序, cts 通过子进程调用这个服务, 是个简单的语言服务服务端, 插件部分是实现的语言服务客户端, cts 的自动补全, 不需要修改 vscode的源码, 是在 ctsvscode 语言服务的插件里实现的 ,也就是这个补全插件只能 .cts 使用. 输入法是可以在 任意语言里面使用的.

[nobodxbodon]

@htwx 多谢确认！这样的话应该可以用类似方法实现其他语言的补全插件了，很期待看到你的插件啊。请问当时为何选择自己实现拼音服务呢？没记错的话 @lightrabbit 他们的好像用了一个node的拼音库？

[htwx]

这个不是 拼音服务 nodepinyin 只能给汉字标注拼音, 这个是输入法, 就是能 你输入拼音返回 符合的词或短语

[htwx]

计算量完全不是一回事

[lightrabbit]

我当时的做法是在vscode对中文字符的候选项进行匹配的时候，把候选项从汉字转为标注的拼音，然后对标注的拼音也进行一次匹配。
接着把对拼音的匹配结果映射回对汉字的匹配。

[htwx]

我这个对已经有的 标识符 也是这样, 但是 如果是 需要新起名的时候 例如 声明变量的时候 就需要是输入法了, 或者说是写注释的时候

[htwx]

我把我的插件 也发到这里来得了. 我习惯在 开源中国, 这里的界面全是英文的我 操作不好

[nobodxbodon]

@htwx 的插件已经发布.
如有意继续此技术路径, 请再开此贴.

[nobodxbodon]

@lightrabbit 不知是否看到了 VSC 的 这个中文标识符补全辅助插件？已支持多种输入法，还有不少方面待完善改进。
顺便 @cleverdango