Support ghc-modi

[darthdeus]

At first I thought this was ghc-mod's fault (DanielG/ghc-mod#253), though it was pointed out to me that unlike hdevtools, which runs a background process, ghc-mod doesn't do such thing and instead uses ghc-modi to avoid parsing the sources every time it's invoked.

As it turns out though, this would have to be supported on the plugin side, which is why I'm opening this issue :)

I'm not sure if such thing is even possible with VIM though? As ghc-modi basically works as a repl to which commands are being sent.

If not, I thought that maybe it would make sense to wrap ghc-mod in a way that it would run the interactive shell as a separate process on the background, and sort of make it behave like hdevtools.

[eagletmt]

Yes, I'd like to support ghc-modi.

I'm not sure if such thing is even possible with VIM though? As ghc-modi basically works as a repl to which commands are being sent.

It's possible with vimproc, though the interactive process has to be managed carefully.

[denibertovic]

What's the status on this? Is it waiting for DanielG/ghc-mod#253 or?

[legrostdg]

any news on this?

[DanielG]

Just a heads up ghc-modi will be deprecated soonish when I get around to implementing the alternative, probably next summer. If all goes to plan ghc-mod will provide a ghci compatible command line/IPCish interface (which will support code execution) as well as a network based IPC interface that regular ghc-mod will use via a daemon that is started on demand.

So if this would need significant amount of work don't bother ;)

[bennofs]

@DanielG isn't that basically what https://github.com/chrisdone/ghci-ng does? So maybe it would be worth joining efforts?

[DanielG]

I thought so too but Chris had no interest in collaboration when I last asked him.

[int-index]

Using ghc-mod is dead slow. I had to modify this plugin so it doesn't kill ghcmod#make when it takes too long.

[mayeranalytics]

Does this issue have anything to do with the sub-par performance I'm encountering?

[liskin]

See #102 for another attempt to close this issue.