Open PierreR opened 8 years ago
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.
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).
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
) ?
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.
I mean the situation ghc-mod
does not work completely (e.g. error from cabal-helper
)
Instead of guard time, I changed just not to browse module that failed once. PR #24.
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 ?
How did you disable it. I've run in the same problem and it makes writing Haskell really tedious.
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.
I am using spacemacs where the Haskell environment is provided by Haskell layer.
5.1.2018 14.24 "Iku Iwasa" notifications@github.com 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 https://github.com/iquiw/company-ghc/issues/23#issuecomment-355543115, or mute the thread https://github.com/notifications/unsubscribe-auth/ASkUc6yfsOpoIyE052irlom7L6jGrOLyks5tHhRwgaJpZM4Gg87O .
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
In
spacemacs
withstack
(I don't know if this is related to howghc-mod
integratesstack
), the completion will be unbearably slow as soon as the import list is too big (~ 25 items).Is there any known trick to avoid the problem (apart from disabling
company-ghc
) at that point ?Thanks for your help.