V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
pony279
V2EX  ›  Vim

Deoplete 也可以在 vim8 上跑了

  •  1
     
  •   pony279 · 2017-10-15 19:36:01 +08:00 · 10092 次点击
    这是一个创建于 2357 天前的主题,其中的信息可能已经有所发展或是发生改变。
    第 1 条附言  ·  2017-10-16 17:55:34 +08:00
    扎心啊,deoplete 又涨了一波 star,我的几个插件都没啥动静
    36 条回复    2018-02-05 13:11:29 +08:00
    tracyone
        1
    tracyone  
       2017-10-15 19:52:23 +08:00
    厉害~~
    SpaceVim
        2
    SpaceVim  
       2017-10-15 20:05:49 +08:00
    这个厉害了。
    BBCCBB
        3
    BBCCBB  
       2017-10-15 21:17:45 +08:00
    试试,nvim-complete-manager 在我电脑上不能运行。。
    glues
        4
    glues  
       2017-10-15 22:18:11 +08:00
    感觉还是不如 YCM 快,不过 YCM 安装要麻烦点
    yuuko
        5
    yuuko  
       2017-10-15 23:02:16 +08:00
    楼主厉害了,不过已经用你的 NCM 很久了,感觉还是 NCM 快点
    congeec
        6
    congeec  
       2017-10-16 11:52:37 +08:00
    继续用 Ycm,没有给力的基于语义补全,前端再叼都没用
    pony279
        7
    pony279  
    OP
       2017-10-16 11:59:01 +08:00
    @congeec

    没明白你的意思,具体哪个功能 YCM 有,其他插件都没有?
    pony279
        8
    pony279  
    OP
       2017-10-16 12:05:14 +08:00
    @BBCCBB

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


    :help NCM-trouble-shooting

    vim-hug-neovim-rpc 也可以开启日志,另外需要仔细阅读 Requirements 部分的内容
    BBCCBB
        9
    BBCCBB  
       2017-10-16 12:21:17 +08:00
    好,晚上回去好好测试一下,然后提供给你哈
    BBCCBB
        10
    BBCCBB  
       2017-10-16 12:23:12 +08:00
    @congeec 大家都用的 clang, jedi, yarn/tern 这种, 不存在没有给力的语义补全这种说法吧老哥.
    congeec
        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 要好用
    pony279
        12
    pony279  
    OP
       2017-10-16 17:44:12 +08:00
    @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
        13
    ashfinal  
       2017-10-16 19:25:52 +08:00
    ncm 还是很好用的,我给你发个帖子宣传一下? 😝
    ashfinal
        14
    ashfinal  
       2017-10-16 19:34:06 +08:00   ❤️ 1
    BBCCBB
        15
    BBCCBB  
       2017-10-16 20:25:59 +08:00   ❤️ 1
    @pony279 老哥,我那个问题和![]( https://github.com/roxma/vim-hug-neovim-rpc/issues/9)这个问题一毛一样,已经照着该 issue 里的方法解决了,也是 Windows 上的问题。。 在我的 Mac 上没问题, 🙏,非常好用,vim8 有一个 completor.vim, 不过该插件支持较少。。。
    simple26
        16
    simple26  
       2017-10-16 22:30:27 +08:00
    其实 我觉得要是可以的话 你自己写的一些补全 source 可以不用再额外开一个单独的 repo 感觉会分散注意力。。go rust c/c++ javascript 等等这些更多 builtin 的话感觉能使 NCM 更饱满:)
    jsfaint
        17
    jsfaint  
       2017-10-17 07:45:24 +08:00
    @BBCCBB #15 completor.vim 的 clang 插件有卡死的 bug,给作者提 issue 提了快一年了,有十几个人都说复现了。作者连条回复都没有。
    反观 @pony279 给力多了,给他提的 issue,提的 pr,还有建议啥的都迅速处理了。
    deoplete 本身还不错,可是 deoplete 的扩展质量参差不齐,至今还有几个在 windows 平台运行有 bug 的
    deoplete-clang2 偷按键,造成根本没法正常映射 tab,作者也不提供任何设置关闭那个功能
    jsfaint
        18
    jsfaint  
       2017-10-17 07:52:01 +08:00
    @simple26 #16 之前想把 gtags source 合并到 ncm 里面,被 @pony279 拒绝了,他觉得需要调用额外工具的 source 不适合进入到 ncm builtin source。ncm 目前 builtin 的 go,python source 是历史原,因本该也移到单独的 repo 里
    simple26
        19
    simple26  
       2017-10-17 08:41:58 +08:00
    @jsfaint @pony279 这么考虑当然也是有理由的:)

    但是如果是我仅个人仅一个用户的角度来看 配置越简单 功能越全面越好 毕竟单独一个 repo 还要麻烦写一个 Plug 而
    NCM 很可能是一串 Plug ... 最好可以像语法检查的那些插件 比如 ALE “有即可用” 自动补全跟语法检查一样都是调用的外部工具 这一点我比较喜欢 completor.vim 当然了 一家之间而已:)
    BBCCBB
        20
    BBCCBB  
       2017-10-17 08:56:59 +08:00
    @jsfaint
    @pony279
    我觉得, 全部做成单独的 source 插件可能并不好, 参见 `eclipse&idea/vs | atom/vscode` 的不同. eclipse 和 atom 的优点是扩展性, 缺点大概也是扩展性太高, idea/vs/vscode 这种 built-in battery 的东西使用起来更加的舒服, 不用处理各个插件兼容啊什么的.

    不过像 @simple26 你这个合并 gtags,需要安装额外工具的,的确有点不合适并入.. :)
    而像 go,python,js 这种 built-in 个人觉得非常的好!
    jsfaint
        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 一样是历史原因
    jsfaint
        22
    jsfaint  
       2017-10-17 09:04:21 +08:00
    @BBCCBB #20 你这是歧视~~~ go 需要引入 gocode,python 需要引入 jedi,js 需要引入 tern~~~哈哈哈
    BBCCBB
        23
    BBCCBB  
       2017-10-17 09:11:33 +08:00
    @jsfaint 主要是你这个 gtags 不怎么常用啊喂, ==
    jsfaint
        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
    simple26
        25
    simple26  
       2017-10-17 09:34:46 +08:00
    @jsfaint 有可能,不过也有可能因为 swift 的补全工作要比 go rust 这么仅需要一个 daemon 的来得多 所以 completor.vim 把它单独了一个 repo 像只需要一个 daemon 就能工作的感觉还是“能省则省”
    jsfaint
        26
    jsfaint  
       2017-10-17 09:38:18 +08:00
    @simple26 #25 同意,感觉你说的有道理。不过 completor.vim 作者不修 clang 的 bug,不回 issue,我已经粉转路人了
    pony279
        27
    pony279  
    OP
       2017-10-17 11:16:31 +08:00   ❤️ 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。然而这种方案在一开始确实比较难吸引用户。
    jsfaint
        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 的性能确实挺惨的。。
    BBCCBB
        29
    BBCCBB  
       2017-10-18 16:51:33 +08:00
    glues
        30
    glues  
       2017-11-03 15:27:28 +08:00
    为什么只能基于当前的 buffer 做关键字补全,不能跨 buffer 吗?

    ps:这个插件有 QQ 或者微信群吗,相互交流一下?
    henices
        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.
    jsfaint
        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 上都是秒开
    pony279
        33
    pony279  
    OP
       2017-12-12 17:48:55 +08:00
    @jsfaint hmm... 没有在 Windows 平台测试过
    pony279
        34
    pony279  
    OP
       2017-12-14 11:53:31 +08:00
    @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
        35
    jsfaint  
       2017-12-14 17:33:58 +08:00
    @pony279 #34 嗯,昨天和 shougo 在 gitter 上讨论了好久,at 你没反应。哈哈哈
    jsfaint
        36
    jsfaint  
       2018-02-05 13:11:29 +08:00
    @glues #30 跨 buffer 你需要这个 plugin
    https://github.com/fgrsnau/ncm-otherbuf
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2613 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 15:35 · PVG 23:35 · LAX 08:35 · JFK 11:35
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.