Hi Richard, great to hear, I've also seen a tweet about new videos from you using VS code (had no time to watch yet). Hope that more adoption improves things! So, I've been using VS Code for almost a year now and I have seen great improvements - almost all of that is the Haskell LSP. "processing" and "indexing" may be (at least the former?) the LSP, I guess? I have head single instances where it went haywire and I had to do a hard reset of my machine, but generally I can work with VS code and LSP doing it's thing (Laptop with Ryzen 4700U & 16 GB RAM). You can hit Ctrl+Shift+P for the command HUD and type "Haskell" - this gives you the options to stop and (re-)start the LSP. The latter can help when it becomes sluggish. In File -> Preferences -> Settings search for "Haskell", there you have the option to turn off things, e.g., "Haskell: Diagnostics on Change" (turning off will create diagnostics only when you save). Hope that helps. Cheers, Ben Am Mo., 20. Sept. 2021 um 17:29 Uhr schrieb Richard Eisenberg < lists@richarde.dev>:

Hi devs,

I have migrated to use VSCode instead of emacs. There are the usual switchover pains, but I'm mostly pleased. One particular point of pleasure was that I had to do nothing, at all, to get VSCode working within the GHC code base. (Well, I had to switch to Hadrian, but perhaps that's for the best.)

My problem: VSCode over GHC pins my processor at 100% if I edit anything. Any advice for fixing this?

A little more detail: When VSCode starts up, it spends a while "processing" and "indexing" (no idea what these mean). OK. I can pay that one-time cost. But as I start editing, etc., it needs to process and index a lot more. Somewhat continuously. This slows my computer down generally, and -- more annoyingly -- slows down my builds (run in a separate terminal).

I understand why VSCode wants to do this: it's checking my code for errors, etc. But is there a way to say "not now, please"? More specifically: I'd like to stop VSCode from detecting errors in my code while I'm actively editing. It's just too slow. On the other hand, it would be brilliant if VSCode could continue to allow me to, say, jump to definitions and gather references, using its latest knowledge of the code. As I edit, I understand this "latest knowledge" may become stale, if I'm stopping VSCode from reprocessing and reindexing. So, it would be nice to be able to tell VSCode to refresh, when I want that.

Any pointers here? https://gitlab.haskell.org/ghc/ghc/-/wikis/Visual-Studio-Code would be a good place to put them!

Thanks, Richard _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Richard Eisenberg writes:

Hi devs,

I have migrated to use VSCode instead of emacs. There are the usual switchover pains, but I'm mostly pleased. One particular point of pleasure was that I had to do nothing, at all, to get VSCode working within the GHC code base. (Well, I had to switch to Hadrian, but perhaps that's for the best.)

My problem: VSCode over GHC pins my processor at 100% if I edit anything. Any advice for fixing this?

A little more detail: When VSCode starts up, it spends a while "processing" and "indexing" (no idea what these mean). OK. I can pay that one-time cost. But as I start editing, etc., it needs to process and index a lot more. Somewhat continuously. This slows my computer down generally, and -- more annoyingly -- slows down my builds (run in a separate terminal).

I suspect you are using not just VS Code (which generally performs fairly well on files of "reasonable" size) but also Haskell Language Server; is this so? Indeed it is sadly true that LSP is currently a bit sluggish on GHC. This is something that Matt Pickering has done a bit of work on the past; he may have some concrete guidance for how to improve matters. In the past he has suggested to me that disabling some language server functionality helps matters. Cheers, - Ben