Improve duration until format is possible

[andys8]

Is your enhancement request related to a problem? Please describe.

It takes quite some time until the language server can be used to format a file. This is likely due to the way haskell-language-server loads a session and does multiple things on initialization. But: Especially formatting could be possible early. Especially if a process is forked to do the work (fourmolu). E.g. purescript-language-server allows formatting and still shows that initialization is in progress. So in theory it could be possible to format files before HLS has finished initialization.

Demo

Here is a demo with a small project (https://github.com/andys8/git-brunch).

screencast-2022-10-11_14.43.53.mp4

Format is possible after 13 seconds. For larger projects or without caches this should take longer.
For comparison haskell-language-server-wrapper . takes 16 seconds.

Describe the solution you'd like

Allow formatting files earlier (if possible) while the session is still being loaded.

Describe alternatives you've considered

An alternative is to use a separate plugin to use format files. But in that case we wouldn't need any integration of formatters in HLS. So I wouldn't consider this being an alternative solution.

Another alternative would be to focus on general improvements to make the startup time faster.

Additional context

haskell-language-server-wrapper --probe-tools
haskell-language-server version: 1.8.0.0 (GHC: 9.2.4) (PATH: /home/andreas/.ghcup/bin/haskell-language-server-wrapper-1.8.0.0)
Tool versions found on the $PATH
cabal:          3.8.1.0
stack:          2.9.1
ghc:            9.2.4

Tool versions in your project
ghc:            9.2.4

[michaelpj]

My guess is that we block everything on initializing the cradle, which takes a while. After that so long as the formatter doesn't depend on e.g. the typechecked source it should be fast.

Note that many of our formatters rely on knowing the extensions that are in use in a file, which I think we ultimately get from the GHC flags for the file, which does depend on the build tool giving us the build flags. So it may be a genuine dependency.

[andys8]

Mhm, like this:

haskell-language-server/plugins/hls-stylish-haskell-plugin/src/Ide/Plugin/StylishHaskell.hs

Line 33 in 2255740

dyn <- fmap (ms_hspp_opts . msrModSummary) $ liftIO $ runAction "stylish-haskell" ide $ use_ GetModSummary fp

[michaelpj]

Yeah, that's pretty explicitly depending on GHC stuff being done for the module. Interestingly, in that case I think you could rearrange it so we don't even run the rule at all if we get the extensions from the config file... but in general I think this is going to be a pretty common dependency path for formatters.

[andys8]

Do you think the issue can realistically be improved or should it rather be closed?

[fendor]

I don't think this can be realistically improved, without sacrificing usability or correctness. E.g., configs might contain language extensions, but who knows whether it lists all? If the behaviour isn't uniform, I think usability suffers.

However, maybe we can cache the last known ghc-options for a filepath and use that for formatting on subsequent starts? Might affect correctness, though.

[michaelpj]

I guess I would say that there's a big topic which is something like "time until usable". There are probably things we can do there, but they're probably going to be ones that improve things generally, I don't think we can do anything much for formatters specifically 🤷

[andys8]

Since formatting doesn't seem to be independent of information we're gathering on initialization, I also think the ticket should be closed.