emacs sluggishness due to slow completion with ghc-mod

[iquiw]

emacs sluggishness due to slow completion with ghc-mod

[PierreR]

Any news on that front ? I have just disabled ghc-mod from emacs because it starts failing again (usually it does that after changing the .cabal or stack file), emacs was like breathing again, much more responsive, ...

It reminds me how bad the situation is performance wise. Is there any hope for an improvement ?

[DanielG]

I'd be interested in knowing if the slowness is coming from ghc-mod or actually the Elisp code itself. AFAIK upon opening a file the ghc-mod elisp bits load the list of symbols for each import into Emacs' memory. Does company-ghc does anything special or does it just use that symbol table?

I've been wanting to move completion and matching into the Haskell core proper for a while now because it always seemed like a bad idea to do that in Elisp. Though there are some tradeoffs to consider here. Namely you loose the ability to easily customize the matching method from Emacs since it would have to be embedded in ghc-mod's Haskell bits.

[iquiw]

Does company-ghc does anything special or does it just use that symbol table?

It calls (ghc-sync-process "browse -d -o MODULE") directly.
If it returns nil, the same is called repeatedly when completion happens.
I suppose this causes the problem.

It is possible to change it not to call browse after receiving nil, but with this change, the MODULE won't be browsed even after compilation problem is solved.

I've been wanting to move completion and matching into the Haskell core proper for a while

I also think it is better since ghc-mod knows (or can know) the project details (e.g. packages with version, CPP flags, etc).

[iquiw]

It is possible to change it not to call browse after receiving nil, but with this change, the MODULE won't be browsed even after compilation problem is solved.

I'm considering some "guard time" before browsing MODULE after receiving nil, although I am not sure it solves the problem or not.

@DanielG Aside from the above, is it possible to have a flag, predicate, hook or something in ghc-mod that indicates the project is broken (i.e. if so, we should not call browse) ?

[DanielG]

I'm confused. check returning a failure shouldn't also make browse fail. browse doens't use the state of the current file at all, it just looks at the package databases essentially.

[iquiw]

I mean the situation ghc-mod does not work completely (e.g. error from cabal-helper)

[iquiw]

Instead of guard time, I changed just not to browse module that failed once. PR #24.

[divusmetaphysica]

How did you disable it. I've run in the same problem and it makes writing Haskell really tedious.

[iquiw]

To disable company-ghc, just not to add it to company-backends.

If you meant to disable ghc-mod, it depends on how you enable it.

[divusmetaphysica]

I am using spacemacs where the Haskell environment is provided by Haskell layer. 5.1.2018 14.24 "Iku Iwasa" <[email protected]> kirjoitti:

…

To disable company-ghc, just not to add it to company-backends. If you meant to disable ghc-mod, it depends on how you enable it. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ASkUc6yfsOpoIyE052irlom7L6jGrOLyks5tHhRwgaJpZM4Gg87O> .

[iquiw]

I have not used spacemacs, but it seems that it does not use ghc-mod as default completion.
http://spacemacs.org/layers/+lang/haskell/README.html#completion-support