[jwortmann]

1. Reorder client capabilities for the initialize params according to the order that is used in the specs: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.18/specification/#clientCapabilities
   Maybe that is bit difficult to review - but it seems that it was partly/mostly in that order already, so let's fix the rest.

2. Newly announced capabilities (which we either already used but didn't announce yet, and/or which are new for the initialize params in the 3.18 specs version):

• general.staleRequestSupport
• general.positionEncodings
• workspace.workspaceEdit.normalizesLineEndings
• workspace.executeCommand.dynamicRegistration
  not sure why it didn't have that before, but a while ago there was added support to process dynamically registered commands for code lenses:

  LSP/plugin/session_buffer.py

  Lines 320 to 322 in 17b2e67

  	elif capability_path == "executeCommandProvider":
  	self._dynamically_registered_commands[registration_id] = options['commands']
  	self._update_supported_commands()

• textDocument.codeLens.resolveSupport
• textDocument.rename.honorsChangeAnnotations

4. Removed # exceptional comments for dynamic registration - not sure what that was about, but I think all relevant functionalities should automatically take dynamically registered server capabilities into account via has_capability / get_capability methods.

[rwols]

Removed # exceptional comments for dynamic registration - not sure what that was about,

Most method names to capabilities follow a pattern. But the ones marked # exceptional do not follow that pattern. See the dict _METHOD_TO_CAPABILITY_EXCEPTIONS in plugin/core/types.py.

[jwortmann]

Most method names to capabilities follow a pattern. But the ones marked # exceptional do not follow that pattern. See the dict _METHOD_TO_CAPABILITY_EXCEPTIONS in plugin/core/types.py.

Oh, I see. But I guess we don't have to duplicate that information as additional comments here, so it should be fine to remove that.

[rchl]

I think the correct order is an alphabetical order rather than following the spec order which is likely not even intentional there. With alphabetical order it's easier to find what one is looking for by scanning the list.

[jwortmann]

With alphabetical order it's easier to find what one is looking for by scanning the list.

I think spec order is better than alphabetical order here. For example I wanted to compare which capabilities we are currently missing, so I opened the specs website and compared it to the code in this method, side-by-side. That doesn't work if it's in alphabetical order.

Also if you implemented some new feature, you don't magically know whether there is a new capability for that, or if so what the exact capability name is, so you also need to open the website (or look up the definitions in the protocol types in protocol/__init__.py - but as far as I can tell, these follow the order from the website too). IMO then it's also easier to compare if they are in the same order, rather than having to search alphabetically.

[rchl]

Go with what you prefer, if it helps you.

I'm still not sure if spec order is really intentional and you can rely on things being added at the end.

Maybe overkill but I would rather see some script that matches our capabilities against the spec schema and lists what's supported and what not.