这是一个创建于 2577 天前的主题，其中的信息可能已经有所发展或是发生改变。
第 1 条附言 · 2017-10-16 17:55:34 +08:00
扎心啊，deoplete 又涨了一波 star，我的几个插件都没啥动静
 |
1
tracyone 2017-10-15 19:52:23 +08:00
厉害～～
|
 |
2
nG29DOMuRYTWfcSr 2017-10-15 20:05:49 +08:00
这个厉害了。
|
 |
3
BBCCBB 2017-10-15 21:17:45 +08:00
试试，nvim-complete-manager 在我电脑上不能运行。。
|
 |
4
glues 2017-10-15 22:18:11 +08:00
感觉还是不如 YCM 快，不过 YCM 安装要麻烦点
|
 |
5
yuuko 2017-10-15 23:02:16 +08:00
楼主厉害了，不过已经用你的 NCM 很久了，感觉还是 NCM 快点
|
 |
6
congeec 2017-10-16 11:52:37 +08:00
继续用 Ycm，没有给力的基于语义补全，前端再叼都没用
|
 |
8
pony279 OP @BBCCBB
有空给我发个 issue，报一下环境，调试信息呗~ :help NCM-trouble-shooting vim-hug-neovim-rpc 也可以开启日志，另外需要仔细阅读 Requirements 部分的内容 |
|
9
BBCCBB 2017-10-16 12:21:17 +08:00
好,晚上回去好好测试一下,然后提供给你哈
|
|
11
congeec 2017-10-16 13:34:08 +08:00
@BBCCBB
@pony279 除了 ycm，其他基本上用的都是 https://github.com/Rip-Rip/clang_complete, 实在不如 ycmd. 老老实实等 clangd 成熟，配合相当好用的 nvim-complete-manager 就爽了。 话说我写 rust 的时候是 neovim+nvim-complete-manager+rls，比 vim+ycm 要好用 |
|
12
pony279 OP @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，能把补全框架和补全插件分离也是更好的选择。 |
 |
13
ashfinal 2017-10-16 19:25:52 +08:00
ncm 还是很好用的，我给你发个帖子宣传一下？ 😝
|
|
14
ashfinal 2017-10-16 19:34:06 +08:00  1
[在 Markdown 及 rst 文档中使用代码补全功能]( https://macplay.github.io/posts/zai-markdown-ji-rst-wen-dang-zhong-shi-yong-dai-ma-bu-quan-gong-neng/)
|
|
15
BBCCBB 2017-10-16 20:25:59 +08:00 1
@pony279 老哥，我那个问题和这个问题一毛一样，已经照着该 issue 里的方法解决了，也是 Windows 上的问题。。 在我的 Mac 上没问题， 🙏，非常好用，vim8 有一个 completor.vim, 不过该插件支持较少。。。
|
 |
16
simple26 2017-10-16 22:30:27 +08:00
其实 我觉得要是可以的话 你自己写的一些补全 source 可以不用再额外开一个单独的 repo 感觉会分散注意力。。go rust c/c++ javascript 等等这些更多 builtin 的话感觉能使 NCM 更饱满:)
|
 |
17
jsfaint 2017-10-17 07:45:24 +08:00
|
|
18
jsfaint 2017-10-17 07:52:01 +08:00
|
|
19
simple26 2017-10-17 08:41:58 +08:00
|
|
20
BBCCBB 2017-10-17 08:56:59 +08:00
|
|
21
jsfaint 2017-10-17 09:01:49 +08:00
@simple26 #19 从用户角度当然是开箱即用最好。作为用户我是挺怕 neocomplete/deoplete 那种需要调教才能用的 plugin
不过单个仓库维护也是好处的，插件的变动不会影响到 ncm 核心部分，可以单独维护。比如之前给 neoinclude 和 neco-syntax 增加 ncm source，其实我有点怕把 shougo 的仓库搞乱了 ：） 说起来 completor.vim 好像也把一部分 source 新增成单独仓库了，估计也和 ncm 一样是历史原因 |
|
22
jsfaint 2017-10-17 09:04:21 +08:00
@BBCCBB #20 你这是歧视~~~ go 需要引入 gocode，python 需要引入 jedi，js 需要引入 tern~~~哈哈哈
|
|
24
jsfaint 2017-10-17 09:19:37 +08:00
@BBCCBB #23 如果你不做 C/C++可能确实用不到，如果做 C/C++强烈建议试用 ：）
gtags 的体验要比 ctags 好的多，速度快，支持多种搜索，支持增量更新 https://github.com/jsfaint/gen_tags.vim |
|
25
simple26 2017-10-17 09:34:46 +08:00
@jsfaint 有可能，不过也有可能因为 swift 的补全工作要比 go rust 这么仅需要一个 daemon 的来得多 所以 completor.vim 把它单独了一个 repo 像只需要一个 daemon 就能工作的感觉还是“能省则省”
|
|
26
jsfaint 2017-10-17 09:38:18 +08:00
@simple26 #25 同意，感觉你说的有道理。不过 completor.vim 作者不修 clang 的 bug，不回 issue，我已经粉转路人了
|
|
27
pony279 OP 1
@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。然而这种方案在一开始确实比较难吸引用户。 |
|
28
jsfaint 2017-10-17 15:53:00 +08:00
@pony279 #27 其实分开单独仓库还好，毕竟这 plugin 本来就是给开发者用的。简单的配置成本开发者都能接受
asyncomplete 目前存在几个问题： 1. 作者想要拿掉 python 支持，但是目前全用 vimscript 的实现有很多奇奇怪怪的 bug 2. source 都单独剥离出来了，source register 却还要自己在 vimrc 里去 register，这有点奇怪 3. vimscript 的性能确实挺惨的。。 |
|
29
BBCCBB 2017-10-18 16:51:33 +08:00
|
|
30
glues 2017-11-03 15:27:28 +08:00
为什么只能基于当前的 buffer 做关键字补全，不能跨 buffer 吗？
ps：这个插件有 QQ 或者微信群吗，相互交流一下？ |
 |
31
henices 2017-11-09 14:33:18 +08:00
[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.
|
|
32
jsfaint 2017-12-12 15:02:10 +08:00
😂 @pony279 rox 你有在 Windows 上用过么？ gvim + deoplete + nvim-yarp + vim-hug-neovim-rpc
我这边在 Windows 速度特别慢，大概要等 5，6 秒才会弹出补全窗口，但是在 Linux 和 mac 上都是秒开 |
|
34
pony279 OP @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. 大概是这样？ |
|
36
jsfaint 2018-02-05 13:11:29 +08:00
|
Select Language