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

Make vscode/hls compatible with SPJ #623

Open
hasufell opened this issue Jun 13, 2022 · 1 comment
Open

Make vscode/hls compatible with SPJ #623

hasufell opened this issue Jun 13, 2022 · 1 comment

Comments

@hasufell
Copy link
Member

@simonpj had a few issues when setting up VSCode with HLS:

  1. Setting up VScode with WSL2 requires a lot of work: https://code.visualstudio.com/docs/remote/wsl-tutorial
    we should document that better or maybe automate it
  2. a lot of HLS plugins that impact performance are enabled by default and as such slow down working on big codebases like GHC. Adjusting this should be documented well. The GHC repository could also include a project-specific vscode config file that does this for all developers.
  3. confusing popups, e.g. Toolchain management dialog: add hint for beginners #621

@fendor @runeksvendsen

@codygman
Copy link

codygman commented Aug 10, 2022

a lot of HLS plugins that impact performance are enabled by default and as such slow down working on big codebases like GHC.

In my opinion this should be treated like game developers treat 60 fps in that anything that takes too long or whose space usage doesn't scale better than quadraticly should be disabled.

Maybe core plugins could be:

  • linting/squiggly
  • type on hover
  • auto-complete
  • import suggestions

Notably this excludes wingman because on my large work codebase it always times out and disabling it in past versions sped things up.

Typed holes (this makes me sad) should be tamped down or disabled until they are sped up. I've has hls crash after timing out a long time on a typed hole in a big module.

Maybe even performance profiles for sets of plugins could be nice:

  • super fast
  • fast
  • typical
  • featureful
  • everything

Because knowing which plugins to disable or finding out is a good amount of work .

This would also allow people to improve performance for their desired performance profile (or the one their huge codebase has them stuck with).

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