Don't restart servers when userprefs change

[jwortmann]

Currently, all language servers are restarted whenever the user settings in LSP.sublime-settings are saved. This is not really necessary, so with this PR they are only restarted if the "clients" setting (containing the server configs) is actually modified.

Note that not all UI features are immediately redrawn when the user settings change. For example if you change "diagnostics_gutter_marker", it still uses the old icons until new diagnostics arrive (usually after next buffer modification). That is because the icon is stored directly in the DiagrosticSeverityData object https://github.com/sublimelsp/LSP/blob/5891ff41deaa781783effeb97c978b3e50bd0a26/plugin/core/views.py#L68-L78

which was maybe not the optimal design choice, but I didn't want to do huge refactorings here.

Or for example if inlay hints get enabled/disabled, they are only added or cleared after the next buffer modification, but I think that should be okay.

[predragnikolic]

I have not tested this, but based on the code that I see

Previously, if someone modified server settings, because LSP restarts the server on setting change, the server would pick it up the new changes once started again.

Now in this PR, LSP will not restart the server, when we change server settings, thus the server will not pick up new setting changes.

In order to address this, the server would now need to be notified with didChangeConfiguration.

---

related to https://github.com/sublimelsp/LSP/issues/2044

[jwortmann]

The server settings are part of the "clients" setting, so if they are modified, servers are still restarted.

didChangeConfiguration would need to be implemented separately.

This PR is only for the userprefs, i.e. UI settings and other LSP settings. It is not directly related to #2044.

[rchl]

Or for example if inlay hints get enabled/disabled, they are only added or cleared after the next buffer modification, but I think that should be okay.

Honestly, I'm not sure whether that's OK. That means that you touch some setting and now all the open views start missing something (semantic highlighting, for example). Now you have to either poke all the views or restart ST which kinda defeats the point of this fix. I think we would have to do the right thing and update every functionality that might be affected.

[jwortmann]

That means that you touch some setting and now all the open views start missing something (semantic highlighting, for example).

Semantic highlighting does get redrawn (added/removed) after changing the corresponding setting value. I think it should only be the inlay hints which are not updated yet (unless there is another feature that I missed); mostly because the phantom handling for inlay hints can be a bit complicated and I didn't write that code, so I haven't analyzed how exactly it works.

Now you have to either poke all the views or restart ST which kinda defeats the point of this fix. I think we would have to do the right thing and update every functionality that might be affected.

Well instead of restart ST you could restart only the language server from the command palette if you want to redraw inlay hints. But I can try to figure out what would need to be done to redraw inlay hints too.

[jwortmann]

Actually for inlay hints we were already doing almost the right thing. The "show_inlay_hints" setting is different in the way that it is only used as the default value for new windows. But we have a command and a menu item to toggle the inlay hints dynamically per window, so I assume the states for all windows that are already opened should not be affected when the global LSP setting is changed.

I think there was a small inconsistency with the settings description in the LspToggleInlayHintsCommand that it would only set the initial state when it was toggled the first time. But this should be fixed now.

---

In contrast to what I wrote above, I saw that semantic highlighting is currently only removed when the setting is turned off, but not added when turned on. I'll take another look later how it can be redrawn directly.

[jwortmann]

Semantic tokens should now be requested/updated if the userprefs change and semantic highlighting is enabled (regardless whether that setting actually changed or not), as soon as the view gets activated. I think this is a good compromise between having the rendering state up to date and not overwhelming the server with many expensive requests.