haskell
Delay server processing: on save, set a configurable delay
Might it be possible to put a delay (configurable, perhaps) of some short time (say, a couple seconds) before firing off the recompile? I'm used to ghcid reacting when I save a file, but having the child GHC process maxing out the CPUs when I'm still in the middle of typing seems a bit overzealous?
AfC
I realized that I would be pretty happy with only rebuilding on error, so set out to see if I could add such a feature myself. I've been looking around in the ghcide code base and couldn't quite figure out what was triggering the shake builds. If someone could point me to which event (ie, it's not "CodeAction" or "Completions" but....) I'd be happy to try and run up a patch.
I don’t really want to change the current behavior in ghcide. If users want a delay this should imho be on the client, i.e. the editor side by limiting the rate at which it sends document updates. As for the code that triggers the updates this is in https://github.com/digital-asset/ghcide/blob/master/src/Development/IDE/LSP/Notifications.hs#L42.
@cocreature fair enough. So this is something that should be changed in the VS Code ghcide extension? (I admit I am overlapping the two conceptually)
Firing off a GHC build—and then cancelling and restarting—every keystroke is making my kernel think it is busy and really ramping the CPU up out of low power mode, resulting in massive laptop battery drain. I had to switch to vim and ghcid while commuting just so my machine would last!
If it works nicely in ghcid, maybe what you want is only checking on save? I think that's something that is in a few extensions, e.g. https://github.com/DavidAnson/vscode-markdownlint/issues/28
Most VSCode extensions offer an option to pick between instant, save or never.
@ndmitchell yeah, checking on save would be great. Changed title. Is this the right repo to have this issue open in?
(certainly a configuration setting like @domenkozar mentions would be a VS Code specific question, but does ghcide need to change to accommodate this?)
Ghcide repo includes the VS Code extension, so yes, it does. It probably also wants to be an option to the Haskell piece, so in the core.
This seems to belongs to the vscode extension so maybe should be transferred to vscode-haskell
@wz1000 sorry it that was the case but the final solution talk about changing the ghcide vscode extension. As the main haskell vscode extension now is this and you can use it to run ghcide, i thought here would be the best place.
It needs to be supported by ghcide.
It probably also wants to be an option to the Haskell piece, so in the core.
I recall in hie we had a kind of hysteresis process in place. If we got changes, from typing, we wait a while (200ms?) for more changes before processing them. Sort of nagles algorithm. So basically while typing is happening we suspend processing, until you stop typing for longer than x ms.
I find the immediate feedback wonderful, way better than some other language servers I use. It costs more CPU, but in most cases that is free. So I think the default should remain minimum latency, regardless of other options.
Perhaps we should put a hysteresis module inline, with a default of 0ms, but which can be configured via a setting? Then everyone gets what they want. It might even make sense to put the machinery into the haskell-lsp library.
And it would be interesting to poll people after a while to see what works best for them.
I'd be inclined to do it in Ghcide rather than lsp. For example, we might decide to cancel execution when we see the key stroke, but not start it again until after the buffer period has passed.