@
simple26 @
jsfaint 早期为了吸引用户，我是倾向于把功能集成越多，越开箱即用越好的，这也是为什么 js, go, python 都是 buitin 的原因，开发这几个 source 难度也比较低。
所以最初的用户主要是写 python 和 js
但是后面从维护角度看，会遇到越来越多的问题
1. 会有不同用户在 NCM 上提和 NCM 核心代码没有直接关联的事情，这对于同样关注 NCM，但是又不使用这类语言的人来说就是信息干扰，那么会更容易 unwatch 这个项目
2. 不同的 source 会有不同的依赖，这同样会导致 NCM 的文档膨胀，造成信息干扰。
3. 时间长了同一个语言会出现不同的选择，比如现在 javascript 有 ternjs 和 flow。如果放在 NCM 里面，我根据个人喜好选择势必会造成另一部分用户的不满。
4. 有些 source 需要针对项目做更多的配置，比如 clang，需要配置和检测 compile_commands.json，而这部分代码的功能可能和同类插件重叠，会造成多余的维护工作。
当然太分散也有不好的地方，将来 NCM 要做一些 breaking change 非常困难，之前就出现过一次改动，然后我接连改了几个 source，然后再给别人维护的 source 发 PR。
对我来说最理想的情况是 NCM 只是一个单纯的补全框架，然后补全 source，连同 goto definition，refactoring 之类的语言支持包作为一个插件维护。
asyncomplete.vim 的作者大概也是这种想法，所以从一开始就没有 builtin。然而这种方案在一开始确实比较难吸引用户。