Add command to toggle server capability #2033
Conversation
|
The list of capabilities seems cool (especially the presentation) but I wonder about usefulness of it... If one wants to quickly and often toggle a capability then it doesn't seem that convenient and keyboard shortcuts would be much better option. I wonder if there is really a good use case for toggling a capability rarely and also have it only persist temporarily. What I envision such list being useful for is with connection with the per-server |
| elif capability == "codeLensProvider": | ||
| for session in self.sessions(): | ||
| for sv in session.session_views_async(): | ||
| if new_state == "on": | ||
| sv.start_code_lenses_async() | ||
| else: | ||
| sv.clear_all_code_lenses() |
There was a problem hiding this comment.
I wonder if it would be cleaner to expose override_capability (or whatever is the appropriate name) on the Session instead since it already has get_capability/has_capability. Feels like it would have better parity there.
There was a problem hiding this comment.
Which then could also be useful for LSP-* plugins to use (see one potential use case in sublimelsp/LSP-css#43).
While the plugin could trigger the command directly instead, it's not ideal as it's "fire and forget" without a return value so there is no feedback that would be good to have in a plugin.
| for session in self.sessions(): | ||
| for sv in session.session_views_async(): | ||
| if new_state == "on": | ||
| sv.view.settings().set("show_definitions", False) | ||
| else: | ||
| sv.view.settings().set("show_definitions", user_setting) |
There was a problem hiding this comment.
Haven't investigated but after disabling hoverProvider for LSP-typescript on a document that runs LSP-eslint and LSP-typescript I'm getting weird flash of content that immediately disappears when showing the popup.
I could investigate if we're gonna proceed with this.
|
Yeah I'm also not convinced if the toggling is useful for most of the features. Besides the inlay hints, I could imagine usecases for the color boxes (which are kind of inlay hints too), and maybe the code lenses. But it doesn't seem very useful to toggle for example the "Goto ..." functionality, since we have the "fallback_command" now anyway. But the main motivation was rather to make the command for inlay hint toggling more generic, so that we don't end up with more of such commands like Another problem I see is that some of the features still have a check whether a setting value is enabled (e.g. But perhaps a better alternative would even be to not restart the servers if any of the setting values is changed. Actually a server restart should only be necessary when things like the starting "command", "enabled", or "initializationOptions" setting is changed. Otherwise it should be sufficient to redraw a particular feature in the view if the corresponding option was changed. But I guess to implement that, LSP would need to store all the previous user settings and compare them to the new values to find out which exact setting has changed. |
That would be better but it would really be nice for ST to provide such functionality. I imagine it can get pretty complicated to diff preferences changes with more complex configuration objects. But if we want to attempt to tackle this then it should be a change on its own. |
|
I suppose at this point my stance is that the generic |
Perhaps there is a simpler solution to it. What if we split the settings file into the regular |
|
I think this is a good idea @jwortmann. I had the same idea about having the server startup info, server initialization options and server settings in separate .sublime-settings files so that we only have to listen for changes in the server startup info and initialization options file to restart a server. Hmm, maybe we only need two files then: For a language server called "foobar":
As an added bonus, it's then "natural" to override LSP-foobar-settings.sublime-settings in the User/ folder without having to deal with DottedDict. |
|
Changing it for LSP-* packages would be quite disrupting but separating But in any case, this is not a strict requirement for this PR. |
…an easily switch to that logic, without breaking changes to the user
|
I guess I can close this draft PR, because it doesn't seem to be very useful in general. I think the proper way to handle the underlying issue would be to split the settings files and never restart servers when LSP's UI settings changes (#2033 (comment)). This would mean to remove I remember that I quickly attempted to start an implementation for that, but I gave up because it wasn't trivial to do it in a backward compatible way. And I think I don't want to invest time for this at the moment. |
|
I would kinda want to have a way to be able to toggle inline hints quickly. But I'm not sure of what's the correct solution for that. As far as not restarting on setting changes I'm a little overwhelmed even thinking about it. It would be quite a massive change for LSP packages and existing users. (Where would we expose settings other then the ones from the |
I'm talking about the settings from the LSP.sublime-settings file, i.e. settings which mainly affect UI and LSP behavior, but not server specific behavior. LSP-* packages would still use their LSP-foobar.sublime-settings file unchanged, and users only need to copy their manual server configs from To also avoid restarting servers when server-specific settings changes, and use |
|
OK, if we ignore LSP packages for now then it should be doable. |
I went ahead and created a draft what I would imagine as alternative to #2023.
Probably needs some thorough testing, but seems to work pretty well so far. I like the list input in the command palette :)
And I realized that diagnostics can't be toggled, because there is no server capability for that.