Allow suppressing UI blocking dialogs

[eugenesvk]

Add 2 user configuration options that would allow to suppress the attention-demanding UI blocking dialogs, instead redirecting warnings/errors to a status message and the full console message

Simple way to close #2545 while preserving the current defaults

Though not all modals are affected since some are invoked by the lsp_utils dependency

Question: is it possible to make that dependency respect config options from this plugin? Or do dependencies "by design" ignore their clients?

[rchl]

I honestly don't think we are gonna accept any of these changes (not in this form). It doesn't make sense to just blindly change all instance of modals. Especially in this file it's a case of explicit user action and it makes sense to report the error in the dialog (the user won't be surprised by it) instead of having to dig for more info in the console or potentially miss the status field message.

[eugenesvk]

The users to whom it makes sense to see these kind of dialogs or who worry about missing a status field message can simply continue to use the defaults. Or they can set the regular dialog suppression setting, but leave the error setting on.

So this setting is simply not for them, but for the other group who have never had an issue of missing a status field message (by the way, you could add ❗ symbol if you think this is a very important message, that's harder to miss), don't see the point of a blocking modal for a simple error message. For them these bad interface design patterns don't make sense because they do not reflect the importance of the messages.

explicit user action and it makes sense to report the error in the dialog (the user won't be surprised by it)

The issue here isn't surprise, but, requiring additional user action for no good reason.

What's your alternative - group/code all the messages and ask the user to provide a list of those that should be suppressed like in lints?

[rchl]

In this case the error is a direct response to user action so it's fine to present a dialog that can be dismissed easily with a single button press.

If you don't like dialogs so much then maybe just create a plugin that overrides sublime.error_message (if that's possible but I think it should)? It's not sensible to expect every package to introduce an option to switch between error dialogs and status field messages.

For some cases I would also prefer to not have dialogs but as discussed in related conversation, there is not necessarily a better way due to ST's limitations.

[eugenesvk]

In this case the error is a direct response to user action

Showing a status message is also a direct response

so it's fine to present a dialog that can be dismissed easily with a single button press.

It's not fine, you need to provide value to the user to demand action from every single user (this is an optional config, disabled by default, so most of the users will continue to suffer through needless actions the way you want them), and in this case you don't - this is simply not an important error message.

Also for some of these cases a blocking message prevents a much better UI: for example, in the next error that appears after theparse VSCode package JSON action instead of a blocking URL must end with 'package.json'" it'd be better to show the same input field again with the old user value and show a non-blocking error message (e.g., in the status bar or maybe in some popup) so you don't lose valuable user input data and allow for the next user action to be error correction instead of UI unblocking

If you don't like dialogs so much then maybe just create a plugin that overrides sublime.error_message (if that's possible but I think it should)?

I don't like needless user actionn, not dialogs, so I don't want to override all the error messages, just the ones that aren't important. None in your plugin are, so I'd be fine with overriding all of them.

It's not sensible to expect every package to introduce an option to switch between error dialogs and status field messages.

I don't expect that, there are plenty of plugins that don't show dialogs, or use less intrusive notifications, and this is a PR for a single package optionally supressing unimportant error messages, not for Sublime core changing everything

[jwortmann]

Here is my opinion:

• I would probably be okay with such a change to remove (most of) the dialog windows, which don't require user input.
• if we want to make this configurable, it should be a single setting and use a better name. Maybe something like suppress_error_dialogs. No need to distinguish between message_dialog and error_dialog imo. But I would probably favor not to add a setting at all for this, unless you want to implement a "don't show this dialog again" checkbox/button.
• the status text should give a reference to the console, like "Failed to start LSP-json - see console for details"
• status message should use the Window.status_message method if possible, not sublime.status_message. And there are likely a few more things to clean up in the code, e.g. don't use local imports. But I haven't looked too closely yet.
• I don't really like emojis as ⚠️ in the status bar or console
• I found the package for notifications: https://facelessuser.github.io/SubNotify/ but unfortunately it is a separate package and not a dependency. While it could be implemented with a fallback (https://facelessuser.github.io/SubNotify/usage/#tips-and-tricks-for-developers), probably no user has that package installed, so it seems more or less useless to use as it is now. Probably out of scope for this PR, but maybe it could be converted to a regular dependency?

[jwortmann]

Question: is it possible to make that dependency respect config options from this plugin? Or do dependencies "by design" ignore their clients?

Yes, should be possible. Just load settings via sublime.load_settings('LSP.sublime-settings').

[eugenesvk]

Updated the PR per the following:

• I would probably be okay with such a change to remove (most of) the dialog windows, which don't require user input.

switched to suppress by default

• if we want to make this configurable, it should be a single setting and use a better name. Maybe something like suppress_error_dialogs. No need to distinguish between message_dialog and error_dialog imo. But I would probably favor not to add a setting at all for this, unless you want to implement a "don't show this dialog again" checkbox/button.

Left the setting given that it's suppressed by default, also re the extra button: Sublime still hasn't learned to properly roundtrip user configs, and this button would change files in the User folder, thus breaking subtle formatting, so I'd just leave it in the currently less convenient format

• the status text should give a reference to the console, like "Failed to start LSP-json - see console for details"

Added a shorter text, otherwise it might not fit

• status message should use the Window.status_message method if possible, not sublime.status_message. And there are likely a few more things to clean up in the code, e.g. don't use local imports. But I haven't looked too closely yet.

switched

• I don't really like emojis as ⚠️ in the status bar or console

They address @rchl concern of users not noticing notifications, ⚠️ make them stand out. I don't mind either way, so removed ⚠️, but left ❗ as I presume those are supposed to still be differentiated somehow

[rchl]

• I don't really like emojis as ⚠️ in the status bar or console

They address @rchl concert of users not noticing notifications, ⚠️ make them stand out. I don't mind either way, so removed ⚠️, but left ❗ as I presume those are supposed to still be differentiated somehow

I do think that there will be a good portion of users that will not notice something showing up in the status field for a few seconds. Or if they do notice something changing, they might not realize what has changed (if the status field is busy).

So as I said, I don't think that status messages are a good solution in general.

I suppose when user is doing an explicit action then he/she might be more looking for some feedback/result and might pay more attention.

If the user doesn't expect anything then it might be easy to miss status change completely.

[eugenesvk]

After checking the manually shortened messages, there is actually no ❗ left, only in the short template when the only thing you see is ❗LSP: see console log… instead of any substatntive message, and since you both don't like them won't adde them to the actual status error messages

I do think that there will be a good portion of users that will not notice something showing up in the status field for a few seconds

Have you actually tried it? It's harder to miss colored ❗ motion in your vision periphery

So as I said, I don't think that status messages are a good solution in general.

By the way, for very important messages you could also use these popups, that's in user's focus (at the cursor) (and of course it could fit the whole message)

[netlify]

✅ Deploy Preview for sublime-lsp ready!

Name	Link
🔨 Latest commit	546a8df
🔍 Latest deploy log	https://app.netlify.com/sites/sublime-lsp/deploys/6746bde86a54c4000889f3b5
😎 Deploy Preview	https://deploy-preview-2546--sublime-lsp.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[jwortmann]

This is true in the settings file.

[eugenesvk]

fixed