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

Support Language Server Index Format files #53

Closed
codygman opened this issue Oct 11, 2019 · 2 comments
Closed

Support Language Server Index Format files #53

codygman opened this issue Oct 11, 2019 · 2 comments

Comments

@codygman
Copy link

codygman commented Oct 11, 2019

Since GHC 8.8+ can now generate Language Server Index Format files via hie-lsif, lsp-haskell supporting them would allow performant lsp features without having to install language servers or having potentially slow language servers running.

This is especially great since Haskell IDE Engine has had performance issues according to many and in my own experience trying to use it. Though there are work arounds such as killing it when it goes over 2GB of memory, that can cause system slowdowns that are a liability to workday productivity.

I believe this is the proper place for supporting these files in emacs, let me know if not.

As a starting point, I guess looking at the vscode blog post for lsif, the LSIF specification, and potentially the vscode-lsif-extension forked to add Haskell support by @mpickering.

Any direction in implementing this or what would be involved in implementing it is much appreciated.

@codygman
Copy link
Author

codygman commented Oct 11, 2019

I found some related discussion in neoclide/coc.nvim#993. To prevent any information not being relayed or lost, I also put out a question on the lsp-mode gitter.im here

@michaelpj
Copy link
Collaborator

I think this probably needs to be supported in lsp-mode. lsp-haskell is just a thin wrapper that tells lsp-mode how to launch a server.

Supporting lsif files should (I believe) be done in a language-agnostic way. When/if lsp-mode supports them then we would need to do whatever work thy require to generate them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants