You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, most of our formatter plugins require the GHC session in order to acquire the DynFlags for a module. This is even true for the CLI modes - most of the plugins still get the flags so that they can pass them to the CLI executable.
This means that formatting is generally going to block until the session is set up. This isn't great: in particular, it's not uncommon to have some kind of format-on-save set up, and that means you can't save a file until HLS is finished setting up! (I think there's also a client problem there: I think it should be the client's responsibility to time out formatting in that case)
So it would be nice if this didn't happen. The best thing I can think of doing is just to let the formatters do whatever they do if they don't get the flags specified. That presumably means guessing them from cabal files etc, but crucially in a way that doesn't block on HLS. It would also make them more likely to line up with how a CLI formatter would operate. Or at least if we're in the CLI mode I think we shouldn't take the flags from HLS, since the whole point is to match what the CLI formatter does.
Probably not the best solution.
When ormolu is requested from the command line, it should do its own
detection of cabal features. If it has to set up the GhcSession just
to get some flags, it blocks saving a file (`formatOnSave = true`),
which is a horrible user experience in cases where the session takes a
minute or more to set up.
Instead, now the plugin only depends on ormolu and the file itself.
Fixeshaskell#4168
At the moment, most of our formatter plugins require the GHC session in order to acquire the
DynFlags
for a module. This is even true for the CLI modes - most of the plugins still get the flags so that they can pass them to the CLI executable.This means that formatting is generally going to block until the session is set up. This isn't great: in particular, it's not uncommon to have some kind of format-on-save set up, and that means you can't save a file until HLS is finished setting up! (I think there's also a client problem there: I think it should be the client's responsibility to time out formatting in that case)
So it would be nice if this didn't happen. The best thing I can think of doing is just to let the formatters do whatever they do if they don't get the flags specified. That presumably means guessing them from cabal files etc, but crucially in a way that doesn't block on HLS. It would also make them more likely to line up with how a CLI formatter would operate. Or at least if we're in the CLI mode I think we shouldn't take the flags from HLS, since the whole point is to match what the CLI formatter does.
Thoughts from formatting plugin maintainers? @georgefst @peterbecich ?
The text was updated successfully, but these errors were encountered: