Completion

[parsonsmatt]

Would be p great to have completion through this too

• Omnicompletion
• Deoplete support

intero and GHCi both have a :complete command which works great for this. Getting this working is going to be fairly tricky, however, as we can only currently acquire results from the Intero REPL asynchronously. The completion functions are required to be called synchronously.

Deoplete support would require the Python code sending a message to the repl, capturing/parsing output, and then collecting the results itself

[expipiplus1]

Using deoplete if possible!

[parsonsmatt]

My current plan is to get an omnicompletion function working through this, which should be usable by deoplete.

[expipiplus1]

The omnicompletion support in deoplete is a little 'second class'. The last I checked it doesn't run asynchronously, and it's not possible to run custom filters over the output.

[parsonsmatt]

Good to know, thanks! I've actually been really pleased with deoplete's omnicompletion with neco-ghc. I'll have to add deoplete completion support as well.

[expipiplus1]

I think that neco-ghc uses the full deoplete completion. The source is here https://github.com/eagletmt/neco-ghc/blob/master/rplugin/python3/deoplete/sources/ghc.py

[parsonsmatt]

I'm removing this from the 1.0 milestone because neco-ghc performs well and I have no issues at all with it. I'm going to leave the issue open so that people can post more information and motivate me to get it done 😄

Why is Intero's completion better than neco-ghcs?

[expipiplus1]

At the moment I'm using ghc-mod with neomake to check the code on write, and neco-ghc to get code completions. There are sometimes differences between these two tools, for example the file might compile with one and not the other. It would be super to be able to replace both of these with just one tool.

[parsonsmatt]

A neomake maker for Intero would be pretty great, but I'm not sure how easy it would be to hook into the REPL since makers seem to want to be CLI executables. I think I'd need to actually figure out how to interact with the REPL instead of the current timeout solution 😨

[Jhana1]

I know this is pretty late, but I would definitely like intero-neovim to have completion. Whilst I use neco-ghc currently, intero completion is definitely superior. Having access to local module completion information is pretty useful, and something ghc-mod is unable to do.

[decentral1se]

intero completion is definitely superior

Can you expand on this one @Jhana1? So far, we have the motivation that it would be better to combine completion and error checking into one tool. However, as above asked by @parsonsmatt, and I'm not clear on it either - is Intero's completion better?

A neomake maker for Intero would be pretty great

So glad this is done now 👍

[parsonsmatt]

I would love to drop the ghc-mod dependency in my vim setup :)

[Jhana1]

@lwm As far as I am aware (and after a quick play around). Intero completion provides two key improvements over ghc-mod. It allows completion info for intra-module declarations, and it allows completion from local modules. ghc-mod only provides completion for installed packages.
For Example: Two files,
A.hs

module A where
plus2 :: Int -> Int
plus2 = (+2)

and B.hs

module B where
plus5 :: Int -> Int
plus5 = (+3) . (+2)

with ghc-mod you would be unable to get file and project local completion, however with intero you can currently do either of :complete repl "str" or :complete-at 'module-name' <line info> "str" to get project local completion info.
so in this case we could do the following in B.hs

module B where
import A
plus 5 :: Int -> Int
plus5 = (+3) . plu

and call :complete-at B 4 15 4 17 "plu" and get the following completion results.

plus2
plus5

whereas with neco-ghc/ghc-mod this completion is not possible.

Hopefully that answers why Intero completion is superior to ghc-mod.

I had a brief shot at trying to add deoplete completion when I commented on this issue, but given the way the callback is structured currently I'm not sure how possible it is (admittedly I am neither a python nor vimscript wizard, someone marginally more talented than I may have a very different opinion).