Discuss removal of some APIs

[predragnikolic]

Some API are not necessary anymore.

While this removal might not happen soon,
I still wanted to give a heads up.

Client configuration

The following api will stay:

• selector
• priority_selector

The following will be deprecated and removed:

• feature_selector
• document_selector
• languages
  • scopes
  • languageId
  • syntaxes

Each package that still uses the deprecated api
will get an update to migrate to selector and priority_selector.

• Remove view2scope - not used
• Remove syntax2scope - not used
• Remove default_clients in a non breaking way

[jwortmann]

There is also uri_to_filename function from the API marked as deprecated for a long time. Maybe it can be removed? (probably better to check LSP-* packages first if it is used somewhere)

• Remove default_clients in a non breaking way

How is this possible in a "non-breaking way"? I'm all for removing the default_clients (even if it would be breaking), but if someone used those configs, it would stop working for them, no? Or what am I missing?

[predragnikolic]

(probably better to check LSP-* packages first if it is used somewhere)

Looks like uri_to_filename is used in:
LSP-copilot
LSP-eslint
LSP-leo
LSP-typescript

[predragnikolic]

Remove default_clients in a non breaking way

I can add code to migrate the "default_clients" to users LSP.sublime-settings "clients" section. (in reality, it would require more code, I would need to merge the "clients" configuration to "default_clients" and then move it to "clients", but you get the point)

I would like to avoid people having to deal with breaking changes, unless they really have to... But that is just nice to have :)
If we just delete the "default_clients" I would be fine with that, and people will be notified about that change in the release notes. Which is also OK.

[predragnikolic]

probably better to check LSP-* packages first if it is used somewhere

The easiest way to see if we are breaking a LSP-pacakge is by cloning
https://github.com/sublimelsp/lsp_maintainers

Should help when doing breaking changes to see what plugins are affected.

Commands:

Preferences: LSP Maintainers Settings - configure what LSP-* will be cloned and included in the project.
LSP Maintainers: Clone Projects - will clone the specified LSP-* plugins in the sublime package directory.
LSP Maintainers: Open Projects - will open the those LSP-* plugins in the current window.

[jwortmann]

Some more which could be considered:

• Remove (deprecate) the Session.set_window_status_async and Session.erase_window_status_async methods - we have Session.set_config_status_async now which does almost the same (the only difference is that you can add multiple status messages at the same time with Session.set_window_status_async because there you need to manually manage the key, and that Session.set_config_status_async wraps the message in parentheses directly following the server name, which is visually more appealing in my opinion).
  The older Session.set_window_status_async is still used in

  • https://github.com/sublimelsp/LSP-OmniSharp/blob/d5cea1febbcc0ba7175353610064c22ece5159b5/plugin.py#L166 (I think it could directly be changed to set_config_status_async)
  • https://github.com/sublimelsp/LSP-jdtls/blob/26277510a3f63a7cb3ad2f71b351307a0744ff5b/modules/protocol_extensions_handler.py#L58 (for a custom language/progressReport notification - this might need a bit refactoring to combine multiple messages into a single status message)

• Remove the language-ids.sublime-settings file and hardcode the language ID mapping instead in the code. I don't really see why this has to be configurable by users. The language IDs are static and are defined in https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocumentItem. I can't think of any use case why you would modify some of that. This would only be necessary if there is there were a server expecting an ID A for a language, and another server expecting a different ID B for the same language (syntax), which seems like a quite constructed and unrealistic use case. I think often the language ID is ignored by servers anyway. If there is any language missing in the current mapping, it should be contributed via a PR, so that all users automatically benefit from it.

[jwortmann]

@rchl Can you enable the "Discussions" tab in this repository? It might also be useful if people have questions or want to request new server configurations, etc.

[rchl]

Enabled