[rchl]

Fix issue mentioned in sublimelsp/LSP-basedpyright#154 where disabling and then enabling LSP-* package triggers weird errors. The same issue can trigger on package updates.

The issue was that on disabling the plugin, the active settings listener from SettingsRegistration would trigger and immediately re-register the external plugin. Fix by explicitly unregistering the listener when unregistering a plugin.

I think I've finally came up with a clean fix for the weird SettingsRegistration listener handling. Now SettingsRegistration is owned entirely by ClientConfigs where both registration and un-registration happens and it's not passed to ClientConfigs. ClientConfig only receives the new SettingsStore with sublime.Settings and settings path - all that it needs.

[rwols]

It's an improvement! But I still see a discrepancy between "LSP: Enable/Disable language server globally" and "Package Control: Enable/Disable Package":

• The "enable/disable language server globally" command seems to work the way I'd expect: the session is detached and stopped for all tabs. And when enabling it, the session is attached again. No closing, and then reopening, of a tab, is necessary.
• The "enable/disable package" command: you can disable something like LSP-ruff, and it detaches the session from the tabs. But when then re-enabling it, I have to first close the tab, and then reopen it. Closing and reopening tabs is necessary for all open tabs.

[rchl]

I would guess some state is not cleaned/reset properly in DocumentSyncListener.
But it fixes what it claims to fix - the errors. :)

[rchl]

Unfortunately this triggers sublimehq/sublime_text#6868 sometimes when re-saving LSP/boot.py. I will try to reproduce this consistently and find a fix or workaround.