-
-
Notifications
You must be signed in to change notification settings - Fork 368
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
The formatting notification is too distracting #381
Comments
Well, with some projects with large code base, Formatting only a single file can take much, much time and indicator spins for a while. If the codebase is relatively small, notification is not shown so regularly. My altenative suggestion is to add an option that "fallback text-based formatting when no progress has been made after N secs"; taking more than a few seconds for formatting code is not so desirable, so we need some escaping hatch for it, I think. |
reason-vscode only shows the notification when the formatting takes too much time. Perhaps we can have a threshold of some kind. I wonder how much time it takes to format a Haskell file (of different code base sizes). |
I noticed this as well, formatting doesn't usually seem to be that time intensive of an operation so it would make sense to debounce it first. |
Formatting can block for other reasons though, like consulting a cradle. Debouncing is always good, even better if done on the LSP client side since it is a crosscutting concern across all progress notifications. |
Worth noting, currently the progress notification only shows for Ormolu/Fourmolu, presumably because the others aren't calling withIndefiniteProgress. The notification doesn't annoy me per se, but what's odd is that it hangs around for almost a second after formatting appears to have finished, even on a trivial file. This could be because we call Ormolu with the idempotency check, which means that everything is actually formatted twice, but it's longer than I'd expect even accounting for that. Anyway, having a threshold of even a second would make this a non-issue for me. |
I am gonna use |
I get the problem that with Requiring me to manually stop hls and interrupt the formatting before I can save the file. |
Possibly if we didn't declare them as cancellable the client would not show a UI element (which I think it might be doing just to show the cancel button). I think it's not really necessary to say they're cancelable. |
Should be fixed now, we will only get a progress notification if it takes some time. |
I think there's really nothing worth notifying when formatting the document, especially when the formatting command has to be triggered by user by default. It becomes even more distracting when you enable, say,
format on save
.There should be an option in the settings for disabling these notifications.
The text was updated successfully, but these errors were encountered: