Consistent/configurable display of alerts about lsp HOT 4 CLOSED

Just some thoughts (as a UX designer)

The popup is designed to show information at the cursor, so for anything that is relevant for that word or line. It's not really a feedback mechanism, as you notice from little things like the position being off.

In general, I don't think it's up to packages to invent new UI conventions, especially for concepts that already exist in Sublime. Currently, if you call a command and it doesn't do anything, you'd glance at the statusbar for a message why it didn't work. It works like that for pretty much everything that is already in Sublime by default, like goto definition. Because it is used everywhere, you'll probably have already learned that it works like that before you try out LSP. It isn't very visible, but in most cases you expect a visual effect if the command works: if nothing happens you already know it didn't work. Also, the feedback is alway in roughly the same spot (the statusbar), which is also good. Not as good as in context or exactly where I'm looking, but at least it's where you expect it, it doesn't get in the way and it's easy to find. The status_message has the added benefit that you don't have to actively dismiss it.
So, "find references" and "go to definition" are using already established conventions, which is more important to end users than anyone's preferences for feedback visibility. If you do get a lot of requests from users to make the feedback more visible, I would add that as an option but certainly not as a default. And it's also an indication that users are not seeing the effects they're expecting to see, so something about your package is hard to use if users rely on the feedback to know if they're using it right (i.e. the feedback visibility is not what you need to solve, the need for feedback is).

Code actions are a bit different. The effect might not be big and very visible, so it's not a bad idea to be a bit louder about feedback that nothing happened. I saw you already have an issue open to try and find out beforehand if there are available code actions and hide the button if not. That's of course preferable. If that's not feasible I would personally opt for using the output panel for feedback that nothing happened. It's the other conventional feedback method that is more visible and allows for more content.

from lsp.

Thanks for your thoughts! I'm with you on the conventions.

Code actions are a bit different. The effect might not be big and very visible

Requesting the list of code actions results in a popup (if actions are available), so that effect is generally visible.
But after executing a code action from that list, it is entirely possible that the changes applied to the document are not visible.
Perhaps we should use the status bar there, e.g.: "X edits applied"?

from lsp.

Perhaps we should use the status bar there, e.g.: "X edits applied"?

That would the most consistent. I guess it could depend on what the actions do, and what info the server provides as feedback of what it did, so I can definitely envision future feature request for verbose feedback. If there are good use cases for that, perhaps you could have a (syntax specific) setting that tells it to put feedback in an output panel. That's probably overkill for an mvp though.

from lsp.

As I've received no complaints about only showing notices in the status bar, I'm closing this proposal for more prominent messaging.

from lsp.