bug#61726: [PATCH] Eglot: Support positionEncoding capability

[Augusto Stoffel]

On Thu, 23 Feb 2023 at 17:04, Eli Zaretskii wrote:

> Then why does Eglot want to know the column at all?

In the Eglot context, "column" simply means "offset since the beginning
of the line", where "offset" can be counted in one of three diferent
ways: codepoints, bytes of the UTF-8 representation, or bytes of the
UTF-16 representation divided by two (a.k.a. code units).

(Number of cells occupied in the terminal is _not_ one of the ways to
count "offset", thankfully!)

I don't think "column" is a particularly confusing name here, but if you
want to rename this, now might be a good opportunity.

>> If you look carefully at the Eglot code, you will see that
>> `move-to-column' only appears in the code pertaining the “UTF-16 way of
>> counting offsets”, which
>> 
>> 1. is old and I didn't touch in this patch,
>> 2. seems to work correctly, despite looking suspicious, and
>> 3. will not be used anymore when both Eglot and the LSP server supports
>>    the positionEncodings capabitily.
>
> Positions do not necessarily transform to columns easily.  So,
> depending on how Eglot uses this information, we may or may not have
> problems.
>
> In general, reporting coordinates in columns between programs is
> problematic.  We see this in many cases, starting with spellers.

Yes, I agree this is problematic -- as soon as you leave the wonderful
world of UTF-8.  The point of this patch is to stay in that wonderful
world as long as the server agrees to it, which I hope will become
commonplace.