LSP integration: inconsistent handling of goto-definition for selected text

• VSCode Version: 1.43.0
• OS Version: macOS Catalina 1.15.3

Triggering goto-definition on selected (e.g. to copy) text depends upon how the text itself was selected.

This is because the goto definition request uses a different text position depending upon the end point of the selection. For a fix, I think it should always use the beginning of the selection as judged by earlier file offset.

Steps to Reproduce:

1. Use any LSP that’s available within VSCode. For my example, I’ll be using https://github.com/apple/sourcekit-lsp on itself
2. I’ll be using the text here:

extension BuildServerBuildSystem: BuildSystem {

Examples:

1. extension BuildServerBuildSystem: BuildSystem { --------------------- ^ ----------- double click to select Goto-definition doesn’t work (VSCode appears to send the position at char :)

2. extension BuildServerBuildSystem: BuildSystem { ------------ ^------------------------^ ------------start------------------- end Goto-definition doesn’t work (VSCode appears to send the position at char :)

3. extension BuildServerBuildSystem: BuildSystem { ------------ ^------------------------^ ------------end------------------- start Goto-definition does work (VSCode appears to send the position at char )

For these cases VSCode should also send the position at char before the selection

[dbaeumer]

I actually disagree. The position that should be used is the one where the cursor blinks. Otherwise it is IMO confusion for the user.

[dbaeumer]

Added this to the spec:

It is up to the client to decide how a selection is converted into a position when issuing a request for a text document. The client can for example honor or ignore the selection direction to make LSP request consistent with features implemented internally.

I think we need a different item if we want to support selections instead of positions.