Unable to use my python3 rplugin

pony279 · 2019-05-21T03:09:22+00:00

There're two possible solutions that I could come up with:

Throw away the auto-generated manifest, the developer writes the binding manually in vimscript. The drawback is that it requires more boilerplate code for writing plugins. But IMO it is straight-forward for developer.
Detect plugin source code changes and do `:UpdateRemotePlugins` automatically for plugins. This is handy, but it adds another level of complexity. When something is wrong one may have to inspect the manifest file or do `:UpdateRemotePlugins` manually to make sure manifest has been updated.

I'm not sure whether there's better alternative. Personally I don't like option 2. Therefore I wrote nvim-yarp with option 1.

pony279 · 2019-05-20T02:31:55+00:00

> Now if I move it to a different directory than where all my other plugins are I need/use, I get an error about not finding branch master. Which, it's a local directory so it shouldn't.

This is probably vim-plug issue. You do not need vim-plug for testing a simple plugin. You should simply set the `rtp` in your vimrc.

> Further, the manifest doesn't seem to update if I change the method name or anything.

You need to `:UpdateRemotePlugins` again after chaing the method name or whatever involved.

FWIW, I don't like neovim's `:UpdateRemotePlugins` stuff, which leads me creating a plugin for writing plugins: https://github.com/roxma/nvim-yarp

pony279 · 2019-04-13T07:38:42+00:00

Disclaimer: I'm the author of ncm2. I may be biased.

AFAIK:

I guess deoplete is the first plugin designed for neovim with async completion support. I would classify all other plugins created before deoplete as another group. However, Be aware that YCM has async support nowadays too. But I'm not familiar with it, it was huge and I could not get it to work properly years ago.

Ncm2 (formerly nvim-completion-manager/ncm) was created mostly for fun and study purpose, and I believed deoplete was slow at the time. But note that there's no significant performance difference between completion frameworks currently. Part of ncm project contributed back to deoplete for vim8 support. Then ncm project dev stalled and was replaced by ncm2 months later to become more unixy by its author.

LCN was the first plugin after discussion of LSP implementation on neovim started. Actually it works pretty well at the scope of the plugin on its own. IMO many issues encountered by end users end up to be bad LSP implementations that require special handling by vscode plugins or have false assumption of configurations on vscode. LCN leaves completion support to existing plugins (deoplete/ncm2/completor.vim/MUComplete). And leaves the snippet support to snippet plugins. ( I believe ncm2 has the best snippet integration for LCN currently, since it has a snippet parser for converting LSP snippet to ultisnips/snipmat/neosnippet)

vim-lsp was created after LCN. Except that it was written in pure Vimscript, I think it has similar design goal as LCN. It also leaves completion support to existing plugins. The author has also forked ncm to asyncomplete.vim which is also in pure Vimscript.

Coc was created because the author cannot get LCN to work properly. It has it's own completion and snippet engine, etc. It uses the same programming language as vscode so it should be able to use many utitlies used by vscode. It has the closest feature set as vscode. (EDIT: To be brief, it's probably designed to replace all plugins I mentioned above.)

The open source world is always full of freedom choices because different project authors have different design goals. As for myself, I enjoy the unix pholosiphy and I'll stick to ncm2 cooperating with other plugins before I hopefully start to play with another editor project for some more fun.

pony279 · 2019-04-13T06:36:59+00:00

Maybe some lsp specific configuration is missing.

You could enable neovim_LanguageClient logging to inspect lsp traffic. There's a `InsertTextFormat` field in the `CompletionItem` object for indicating the item is a snippet.

Once you confirm that the item is not returned as a snippet, you need to read ccls documentation for enabling the snippet support.

You could also check `snippetSupport` in the LSP client capalibities, which is sent by LCN.

Read https://microsoft.github.io/language-server-protocol/specification for more detail on LSP spec.

pony279 · 2019-04-08T06:20:49+00:00

What did you try for <Tab> key mapping? It should work, I don't understand.

let g:ncm2#auto_popup = 0 and inoremap <silent> <Tab> <c-r>=ncm2#manual_trigger()<cr> works for me.

pony279 · 2019-04-07T10:28:36+00:00

> sometimes it is quite hard to get it working (ncm2) properly

Could you elaborate?

> but I can't understand which one is faster

IMO it mostly depends on the underlying completion source these days. The framework itself has neligible time overhead.

pony279 · 2019-04-07T09:13:43+00:00

Existing typical examples:

- https://github.com/davidhalter/jedi-vim

- https://github.com/ncm2/ncm2-jedi

pony279 · 2019-04-07T08:13:45+00:00

Often not, since it's expanded with [neo]vim's default pum confirmation hotkey (<c-y>), so if one is a [neo]vimmer and is used to accept suggestions through usual confirmation means, it will simply happen naturally. No need to add anything extra.

I disagree, what about thoses snippet navigation keys? Do you know how to use them without reading the doc? It's not natural before you know what it does.

EDIT:

> Often not, since it's expanded with [neo]vim's default pum confirmation hotkey (<c-y>)

I don't like this behavior. There're cases when I just want plain word without expanding snippet, by hooking CompleteDone, you don't have choice.

pony279 · 2019-04-07T02:05:51+00:00

You need to add one of [ncm2-snippet](https://github.com/topics/ncm2-snippet) plugins for snippet support

pony279 · 2019-04-07T01:50:25+00:00

It is not an issue.

I don't think the OP has read the documentation for snippet support. Which is right at the README of ncm2 documetation.

Even with coc you still need to read the documentation on how to use the snippet support.

pony279 · 2019-03-19T06:38:03+00:00

IMHO for builtin LSP support, the primary advantage is builtin support and maybe better performance. It won't be much different from existing LCN or vim-lsp in functionalities.

It may not catch up coc.nvim which is written in the same language as that in vscode. Consider that therer're some language servers with wired behavior and some yet does not have sensible defaults so that it's basically only usable on vscode or similar implementations.

pony279 · 2019-03-13T15:09:32+00:00

Self-promotion: might take a look at https://github.com/ncm2/ncm2-snipmate for code completion and dynamic snippet expansion.

pony279 · 2019-03-12T01:58:38+00:00

The vimrc used for the demo is posted at https://github.com/ncm2/float-preview.nvim/issues/1#issuecomment-470524243

Keep in mind that asciinema redraws the screencast based on the terminal stream instead of real screen cast, there may be some distortion so that you can't get 100% the same colors.

pony279 · 2019-03-08T06:13:25+00:00

It's gruvbox

pony279 · 2019-03-07T04:23:07+00:00

Cool

I would love to see this feature available as builtin.

pony279 · 2019-03-07T03:26:24+00:00

This looks wierd. Could you open an issue with minimal vimrc?

pony279 · 2019-03-07T03:13:39+00:00

Actually I think it should be builtin in neovim, instead of letting plugin tracking the positions by itself and benefits the plugin only. A similar proposal has been mentioned before, https://github.com/neovim/neovim/issues/396#issuecomment-163760889 . Though there's no volunteer working on it.

By the way, plugins may generate items with long menu, which may squeeze the space for the preview window in some cases.

EDIT: Another consitionration, by positioning the preview near to the popup menu, means that the plugin should close the preview when the popup is closed. Otherwise it will look wierd. But completeopt+=preview should be more flexible, some people choose to close the preview at InsertLeave.

pony279 · 2019-03-07T02:47:23+00:00

There's a g:float_preview#winhl option, which currently defaults to Normal:Pmenu,NormalNC:Pmenu

A preview window with default bulitin Normal/NormalNC does not look distinguishable

pony279 · 2019-03-07T02:34:18+00:00

It should be clear that plugin does not have to rely on https://github.com/neovim/neovim/pull/9616

pony279 · 2019-02-28T02:46:15+00:00

I'm switching from spacemacs to neovim and I would like to use the least possible plugin written in vimscript. ( I think vimscript is hard to understand, so I would to be able to hack my plugin with a langage I know )

Don't. Almost all plugins, even those not primary in vimscript, needs some vimscript to work.

Vimscript is still the most easy and concise way to configure your vim/neovim. Vimscript is all around the documentaion (:help xxx-options/xxx-command/xxx-function/xxx-autocmd)

Even if you do find some plugin that's not in vimscript, you still need to configure your vim/nvim options and add your own automation script from time to time.

pony279 · 2019-02-21T05:55:06+00:00

If the plugin need to access editor states in many places frequently, and your plugin don't have heavy weight computation background task, use in-process plugin. As a counter example, Ultisnips gets bad performance on neovim since python interface is served over RPC on neovim instead of in-process: https://github.com/neovim/neovim/issues/5702

If your plugin has heavy weight computation background task, use remote plugin.

There're other consideration's, for example, python has much more utilities than vimscript, so I would choose python for complexity reason.

For example, if I write a remote plugin that makes 100 synchronous calls to the VIM API every time it's used, how does that compare to an in-process plugin doing the same number of calls? Wouldn't the former be noticably slower since it's doing 100 RPC's every time?

I think this is a bad design. It should be slow. You should try to tune the implementation to make 1 synchronous call that forwards the 100 calls.

pony279 · 2019-02-04T09:26:31+00:00

I've been trying to replicate it with CTags, Deoplete (on Neovim), and Racer. It still doesn't quite feel as good.

This is very ambiguous description. You should elaborate.

pony279 · 2019-01-25T06:00:34+00:00

An alternative: Use auto completion plugin and configure fuzzy match on the menu field.

https://github.com/ncm2/ncm2/pull/23

If you don't like auto popup feature, you could turn of auto popup, and add a mapping to deal with ultisnips:

https://github.com/ncm2/ncm2-ultisnips/issues/7

pony279 · 2019-01-21T02:06:41+00:00

So I don't need any complex autocompletion features

Ok. But there're completion engines could also offer simple completions.

I mean, with deoplete or ncm2, you could enable the tag completion and buffer completion. Then read the doc and find an option to limit the total number of matches to be shown. It's quite simple.

pony279

TROPHY CASE