Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integration with deoplete #1753

Closed
docwhat opened this issue Jul 23, 2018 · 30 comments
Closed

Integration with deoplete #1753

docwhat opened this issue Jul 23, 2018 · 30 comments

Comments

@docwhat
Copy link
Contributor

docwhat commented Jul 23, 2018

At the moment, deoplete and ALE's completion fight and cause weirdness.

I can make them play better together by putting finish at the top of autoload/ale/completion.vim to prevent any ALE completion loading.

However, I'd prefer if they just played well together.

This was mentioned as an item for the 2.0.0 roadmap...

@docwhat
Copy link
Contributor Author

docwhat commented Jul 23, 2018

Hack:

diff --git a/autoload/ale/completion.vim b/autoload/ale/completion.vim
index 7440f8cd..55694d8d 100644
--- a/autoload/ale/completion.vim
+++ b/autoload/ale/completion.vim
@@ -1,6 +1,10 @@
 " Author: w0rp <devw0rp@gmail.com>
 " Description: Completion support for LSP linters
 
+if exists('g:loaded_deoplete')
+    finish
+endif
+
 " The omnicompletion menu is shown through a special Plug mapping which is
 " only valid in Insert mode. This way, feedkeys() won't send these keys if you
 " quit Insert mode quickly enough.

@docwhat
Copy link
Contributor Author

docwhat commented Jul 23, 2018

In addition, there is no buffer (b:) version of the g:ale_completion_enabled so I couldn't try to resolve this by turning things on and off on the fly (picking the completer than has better results).

@w0rp
Copy link
Member

w0rp commented Jul 23, 2018

I don't have the time to implement integration with deoplete myself, and I don't use it myself. If someone wants to submit a pull request for deoplete integration with some sensible code, I'll be happy to get that in.

I'll add support for a buffer variable for disabling completion for different buffers.

@docwhat
Copy link
Contributor Author

docwhat commented Jul 23, 2018

What completion do you use then?

@w0rp
Copy link
Member

w0rp commented Jul 23, 2018

I just use the completion I wrote for ALE.

@resolritter
Copy link
Contributor

For anyone also interested, I'm working on this. You can see in the example below that it works pretty well but it's not quite as good yet. The [L] symbol represents completion from ALE's omnifunction. It's shown how it comes together asynchronously with the other sources.

asciicast

It does not reliably proc near the dot at the moment. Also it required decoupling and refactoring the design of completion.vim on my end so I've got to make sure the current way still works for people, and suits users looking to extend the exposed functionality.

I think I can open the PR proposal soon. To be clear @w0rp the integration is done through an external source and deoplete integration won't be embedded into ALE. The changes I made were to decouple the completion engine from the Autocmd actions and then expose the functions for usage outside of ALE.

@w0rp
Copy link
Member

w0rp commented Dec 12, 2018

Sure, throw up a PR when you can do so people can look at it. Thanks for working on it. 👍

@chipsenkbeil
Copy link

chipsenkbeil commented Apr 8, 2019

With the release of v2.4, how close are we to it being possible to integrate with external plugins like deoplete? I love ale and use it for my linting/fixing needs, but I also use deoplete to integrate non-LSP completion such as connecting my addressbook to mutt via lbdbq. It's a bit of a battle to get things working split between them.

It looks like the owner of #2143 abandoned the effort. @w0rp, what is your stance on this? Is this on a roadmap given the good progress you've made leading up to v2.4, especially after adding support to manually invoke completion?

@sodiumjoe
Copy link

Came here to ask the same thing.

@resolritter
Copy link
Contributor

Deoplete has it's own system of pattern matching to trigger a completion. ALE had it's own rules and custom regexes. Omnicompletion happens in two steps

  1. get the starting position
  2. get the results

the first thing I did was put them in two separate functions so that deoplete could call them from the outside.


but since step 2 is asynchronous, the caller needs to know when results are ready. I made a callback in the global namespace which anyone, include Vimscript users who don't use other plugins, could use to filter the results before they are displayed. I was unaware that w0rp prefers to do it like this

let g:the_results = [1,2,3]
doautocmd <nomodeline> User ALEHasTheResults

instead of my suggested approach

" you can override this function in your config
function! ALEHasTheResults(results)
endfunction

This alone generated unneeded noise/discussion and could have been solved trivially as I was willing to do whatever way and didn't find this relevant.


The rest of the thread just didn't go anywhere because I was trying to explain that you can't "call to deoplete". Setting variables from VimL, so that Deoplete can read with an eval and decide what to do, is effectively the way to retrieve results.

There's no way to pause the loop once it starts querying the source, so ALE has to employ some mechanism to handle calls coming every 20~milliseconds from Deoplete and return some variable in response. What I was doing with PollCompletionResults is returning an empty array until there are actual results to show, but it can't be just that

  1. It has to differentiate empty array (working) and empty array (no results)
  2. It has to handle timeouts
  3. When the user erases the trigger character it should return something that signals a stop or send a custom event to Deoplete (it has to be evaluated if RPC calls can miss the timeout window and provide a fast enough response)
  4. Caching is cool, but e.g. in Javascript you can modify any module's definition and change the suggestions completely.

I've found so far that polling with a counting mechanism on the Deoplete's side for handling timeouts + cached fallbacks is good enough; of course reading and writing to a global variable or returning from a (fast!) function so that the candidates can be shown as fast as possible.

@w0rp
Copy link
Member

w0rp commented Apr 8, 2019

Now #2132 is done, finishing Deoplete integration is my top priority. Although I'll still have to spend some time fixing bugs and merging pull requests as ever.

@w0rp w0rp pinned this issue Apr 8, 2019
@w0rp w0rp added this to To Do in Old Working List via automation Apr 8, 2019
@w0rp w0rp closed this as completed in 0133126 Apr 23, 2019
Old Working List automation moved this from To Do to Done Apr 23, 2019
@w0rp
Copy link
Member

w0rp commented Apr 23, 2019

I have now added integration with Deoplete which at least works to some degree. Please try it out, and open further issues for improvements. I was able to get it to the point where it can ask ALE if the requests are complete and then later return the results when they are, and where refreshing the results asks ALE to request results again. It works with my usual TypeScript project, so that's a good enough place to start.

Thanks to @reaysawa for the initial effort on this. The information provided was very useful.

@dsifford
Copy link
Contributor

dsifford commented Apr 23, 2019

@w0rp Just an FYI: g:deoplete#sources was deprecated on 04/09/2019 so your docs are a smidge outdated in this repo.

Edit: I'd also suggest setting the rank of the ale source much higher than 100 because it's getting buried for me by the around source (and prob also buffer) which is rank 300.

@w0rp
Copy link
Member

w0rp commented Apr 24, 2019

Sure, feel free to create pull requests for those changes. I'm not aware of what to use instead of deoplete#sources, I just used the first thing I found in the Vim help file, which doesn't mention it being deprecated yet.

@masaeedu
Copy link

masaeedu commented Apr 29, 2019

Hi @dsifford. Do you know what the correct way to register ale as a completion source is now? I've been trying to use sources as indicated in the ALE README and completion doesn't seem to be working.

@moon-stripe
Copy link

I think it's supposed to be like this:

call deoplete#custom#option('sources', {
      \ '_': ['ale', 'buffer', 'around'],
      \})

But I couldn't get it working either.

@dsifford
Copy link
Contributor

@masaeedu It works fine for me with the following additions to my vimrc...

let g:deoplete#enable_at_startup = 1

call deoplete#custom#source('ale', 'rank', 999)

No need to re-register the source since @w0rp already did it in the plugin.

@w0rp
Copy link
Member

w0rp commented Apr 30, 2019

Feel free to create a pull request to update the documentation to suggest whatever is now recommended for Deoplete.

@chipsenkbeil
Copy link

Can't get it to trigger for me, whereas toggling ALE's completion works fine. I'm assuming I've got something wonky in my configuration, so I'll need to set up a minimal vimrc to figure out what yields a working state.

@dsifford
Copy link
Contributor

@chipsenkbeil I should also note that it's important to have g:ale_completion_enabled either unset, or set to 0.

@thenewvu
Copy link

thenewvu commented May 9, 2019

OH ... I think I did a mistake, I had g:ale_completion_enabled = 1, so please nevermind this.

For anyone else, make sure that you don't have g:ale_completion_enabled = 1 in your configuration file if you're trying out deoplete with ale as source.

Hello @w0rp, it looks like ALE filters completion suggestions by the current line prefix, but this makes deoplete's fuzzy matching unusable. Could you consider to intruduce an option to opt out filering by the line prefix?

https://github.com/w0rp/ale/blob/01331266a84859d4b0935b81ae773ff0d7af7522/autoload/ale/completion.vim#L108

@w0rp
Copy link
Member

w0rp commented May 11, 2019

I just updated the documentation to make it painfully obvious that you shouldn't turn that setting on if you want to use Deoplete or another completion plugin with ALE as a completion source. You shoudn't be able to read about that setting anywhere in the documentation without it telling you not to turn it on if you want that.

@w0rp w0rp unpinned this issue May 11, 2019
@w0rp
Copy link
Member

w0rp commented May 16, 2019

I'm reopening this. I removed all of the code for supporting Deoplete for now because it caused this bug: #2492

Support can be added back in after it works without causing annoying problems for people. If anyone has any idea how to get it to actually work, please give it a try. I can't figure out how it's supposed to work, and as far as I can tell I did everything the documentation told me to do. I'll ask Shougo if he has any ideas.

@w0rp w0rp reopened this May 16, 2019
Old Working List automation moved this from Done to To Do May 16, 2019
@w0rp
Copy link
Member

w0rp commented May 16, 2019

Shougo/deoplete.nvim#976 I asked for some advice.

@dsifford
Copy link
Contributor

@w0rp have you given this a look yet for ideas?

https://github.com/autozimu/LanguageClient-neovim/blob/next/rplugin/python3/deoplete/sources/LanguageClientSource.py

Seems like that and ALE would be extremely similar applications.

@moritzheiber
Copy link

For the record, I also have LanguageClient-neovim installed (and I reported the deoplete support to be sort of broken the last time)

@w0rp
Copy link
Member

w0rp commented May 19, 2019

I don't know why it didn't work properly. It looked like the code I wrote was doing everything the documentation said I should do. Maybe someone else can take a look.

@dsifford
Copy link
Contributor

Is there any possibility that the issues that were arisen were due to a faulty keymapping, and not the implementation? I didn't have any issues just before the ale source was removed.

Keymapping the popup menu is notoriously tricky, so it doesn't seem like that possibility would be too far of a stretch.

@w0rp
Copy link
Member

w0rp commented May 19, 2019

I'm concerned that the completion source being present was causing an issue for some people, and taking it away fixed it. It would be nice for it to just work.

@w0rp
Copy link
Member

w0rp commented May 21, 2019

Okay, I've brought the completion source back now. It turned out that the issue was actually a bug in Deoplete, which has been fixed now. If you see that issue again, update Deoplete and it should go away: Shougo/deoplete.nvim#976 (comment)

@w0rp w0rp closed this as completed May 21, 2019
Old Working List automation moved this from To Do to Done May 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants