Provide range or bias direction for go-to-definition etc

Go-to-definition (and others) is triggered on a cursor position. In VSCode, the cursor lies between characters, so ambiguity: the thing on the left or the thing on the right?

A couple of factors make this worse:

• having a selection resolves the ambiguity, but the language server doesn't get to see it. In VSCode a selection usually requires biasing left.
• other editors place the cursor on characters and so have no ambiguity. They always need the language server to bias right.

To illustrate, these screenshots produce the same textDocument/definition request, but want different results.

In vim. This should go to Foo::operator->.

In VSCode. This should go to object.

It'd be nice to have some more information so language servers can make better decisions. Some ideas:

• requests provide optional selection range in addition to cursor position. (block-cursor editors might always provide at least a 1-char range)
• a client capability describing the cursor type. (Language servers could implement heuristics like bias-towards-identifier for cursor-between-char editors, and have the correct behavior for block-cursor editors)

I guess this is mostly an issue with languages that have overloaded operators. constructor and functor calls are common examples in C++.

The issue names no file or test. Begin by reviewing the protocol's position-related request definitions and the proposed selection-range or cursor-capability approaches; done would be an agreed protocol design and corresponding specification change.