Deoplete 也可以在 vim8 上跑了

[pony279]

https://github.com/Shougo/deoplete.nvim/pull/553

扎心啊，deoplete 又涨了一波 star，我的几个插件都没啥动静

[tracyone]

厉害～～

[nG29DOMuRYTWfcSr]

这个厉害了。

[BBCCBB]

试试，nvim-complete-manager 在我电脑上不能运行。。

[glues]

感觉还是不如 YCM 快，不过 YCM 安装要麻烦点

[yuuko]

楼主厉害了，不过已经用你的 NCM 很久了，感觉还是 NCM 快点

[congeec]

继续用 Ycm，没有给力的基于语义补全，前端再叼都没用

[pony279]

@congeec

没明白你的意思，具体哪个功能 YCM 有，其他插件都没有？

[pony279]

@BBCCBB

有空给我发个 issue，报一下环境，调试信息呗~


:help NCM-trouble-shooting

vim-hug-neovim-rpc 也可以开启日志，另外需要仔细阅读 Requirements 部分的内容

[BBCCBB]

好,晚上回去好好测试一下,然后提供给你哈

[BBCCBB]

@congeec 大家都用的 clang, jedi, yarn/tern 这种, 不存在没有给力的语义补全这种说法吧老哥.

[congeec]

@BBCCBB
@pony279
除了 ycm，其他基本上用的都是 https://github.com/Rip-Rip/clang_complete, 实在不如 ycmd.
老老实实等 clangd 成熟，配合相当好用的 nvim-complete-manager 就爽了。
话说我写 rust 的时候是 neovim+nvim-complete-manager+rls，比 vim+ycm 要好用

[pony279]

@congeec


NCM 现在的 c/c++ 补全用的是 ncm-clang
不过 godo definition 还是必须用到 clang_complete。
遗憾的是有 issue 提到性能不如 ycmd，https://github.com/roxma/ncm-clang/issues/3

暂时没有时间解决这些问题

如果不等 clangd，也许最终还是要走 YouCompleteMe 的老路去编译 c/c++。
即便如此，比起 YCM，能把补全框架和补全插件分离也是更好的选择。

[ashfinal]

ncm 还是很好用的，我给你发个帖子宣传一下？ 😝

[ashfinal]

[在 Markdown 及 rst 文档中使用代码补全功能]( https://macplay.github.io/posts/zai-markdown-ji-rst-wen-dang-zhong-shi-yong-dai-ma-bu-quan-gong-neng/)

[BBCCBB]

@pony279 老哥，我那个问题和这个问题一毛一样，已经照着该 issue 里的方法解决了，也是 Windows 上的问题。。 在我的 Mac 上没问题， 🙏，非常好用，vim8 有一个 completor.vim, 不过该插件支持较少。。。

[simple26]

其实 我觉得要是可以的话 你自己写的一些补全 source 可以不用再额外开一个单独的 repo 感觉会分散注意力。。go rust c/c++ javascript 等等这些更多 builtin 的话感觉能使 NCM 更饱满:)

[jsfaint]

@BBCCBB #15 completor.vim 的 clang 插件有卡死的 bug，给作者提 issue 提了快一年了，有十几个人都说复现了。作者连条回复都没有。
反观 @pony279 给力多了，给他提的 issue，提的 pr，还有建议啥的都迅速处理了。
deoplete 本身还不错，可是 deoplete 的扩展质量参差不齐，至今还有几个在 windows 平台运行有 bug 的
deoplete-clang2 偷按键，造成根本没法正常映射 tab，作者也不提供任何设置关闭那个功能

[jsfaint]

@simple26 #16 之前想把 gtags source 合并到 ncm 里面，被 @pony279 拒绝了，他觉得需要调用额外工具的 source 不适合进入到 ncm builtin source。ncm 目前 builtin 的 go，python source 是历史原，因本该也移到单独的 repo 里

[simple26]

@jsfaint @pony279 这么考虑当然也是有理由的:)

但是如果是我仅个人仅一个用户的角度来看 配置越简单 功能越全面越好 毕竟单独一个 repo 还要麻烦写一个 Plug 而
NCM 很可能是一串 Plug ... 最好可以像语法检查的那些插件 比如 ALE “有即可用” 自动补全跟语法检查一样都是调用的外部工具 这一点我比较喜欢 completor.vim 当然了 一家之间而已:)

[BBCCBB]

@jsfaint
@pony279
我觉得, 全部做成单独的 source 插件可能并不好, 参见 `eclipse&idea/vs | atom/vscode` 的不同. eclipse 和 atom 的优点是扩展性, 缺点大概也是扩展性太高, idea/vs/vscode 这种 built-in battery 的东西使用起来更加的舒服, 不用处理各个插件兼容啊什么的.

不过像 @simple26 你这个合并 gtags,需要安装额外工具的,的确有点不合适并入.. :)
而像 go,python,js 这种 built-in 个人觉得非常的好!

[jsfaint]

@simple26 #19 从用户角度当然是开箱即用最好。作为用户我是挺怕 neocomplete/deoplete 那种需要调教才能用的 plugin
不过单个仓库维护也是好处的，插件的变动不会影响到 ncm 核心部分，可以单独维护。比如之前给 neoinclude 和 neco-syntax 增加 ncm source，其实我有点怕把 shougo 的仓库搞乱了 ：）
说起来 completor.vim 好像也把一部分 source 新增成单独仓库了，估计也和 ncm 一样是历史原因

[jsfaint]

@BBCCBB #20 你这是歧视~~~ go 需要引入 gocode，python 需要引入 jedi，js 需要引入 tern~~~哈哈哈

[BBCCBB]

@jsfaint 主要是你这个 gtags 不怎么常用啊喂, ==

[jsfaint]

@BBCCBB #23 如果你不做 C/C++可能确实用不到，如果做 C/C++强烈建议试用 ：）
gtags 的体验要比 ctags 好的多，速度快，支持多种搜索，支持增量更新
https://github.com/jsfaint/gen_tags.vim

[simple26]

@jsfaint 有可能，不过也有可能因为 swift 的补全工作要比 go rust 这么仅需要一个 daemon 的来得多 所以 completor.vim 把它单独了一个 repo 像只需要一个 daemon 就能工作的感觉还是“能省则省”

[jsfaint]

@simple26 #25 同意，感觉你说的有道理。不过 completor.vim 作者不修 clang 的 bug，不回 issue，我已经粉转路人了

[pony279]

@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。然而这种方案在一开始确实比较难吸引用户。

[jsfaint]

@pony279 #27 其实分开单独仓库还好，毕竟这 plugin 本来就是给开发者用的。简单的配置成本开发者都能接受
asyncomplete 目前存在几个问题：
1. 作者想要拿掉 python 支持，但是目前全用 vimscript 的实现有很多奇奇怪怪的 bug
2. source 都单独剥离出来了，source register 却还要自己在 vimrc 里去 register，这有点奇怪
3. vimscript 的性能确实挺惨的。。

[BBCCBB]

https://github.com/roxma/nvim-completion-manager/issues/148, 😆

[glues]

为什么只能基于当前的 buffer 做关键字补全，不能跨 buffer 吗？

ps：这个插件有 QQ 或者微信群吗，相互交流一下？

[henices]

[vim-hug-neovim-rpc] rpc method [nvim_buf_line_count] not implemented in pythonx/neovim_rpc_methods.py. Please send PR or contact the mantainer.

[jsfaint]

😂 @pony279 rox 你有在 Windows 上用过么？ gvim + deoplete + nvim-yarp + vim-hug-neovim-rpc
我这边在 Windows 速度特别慢，大概要等 5，6 秒才会弹出补全窗口，但是在 Linux 和 mac 上都是秒开

[pony279]

@jsfaint hmm... 没有在 Windows 平台测试过

[pony279]

@jsfaint

https://github.com/Shougo/deoplete.nvim/issues/471#issuecomment-351259526


> deoplete performance is bad on Windows.
> It is well known problem.

> If the issue is fixed, the performance problem will be relaxed.


大概是这样？

[jsfaint]

@pony279 #34 嗯，昨天和 shougo 在 gitter 上讨论了好久，at 你没反应。哈哈哈

[jsfaint]

@glues #30 跨 buffer 你需要这个 plugin
https://github.com/fgrsnau/ncm-otherbuf