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

[Augusto Stoffel]

On Fri, 24 Feb 2023 at 17:19, Eli Zaretskii wrote:

> I'm bewildered by my apparent inability to explain what I mean.  So
> let me try with an example.  Suppose the buffer text in question is
>
>    abcde\201xyz
>
> where \201 is a raw byte.  I'm saying that, instead of signaling an
> error, we could send to the server the string
>
>    abcde xyz
>
> where the \201 byte was replaced by the SPC character.  The latter
> string is, of course, perfectly correct UTF-8 sequence, and so doesn't
> violate any specs.
>
> The SPC character as a replacement is, of course, just one example.
> We could instead use '?' or U+FFFD REPLACEMENT CHARACTER, or anything
> else, and all of those replacements can be encoded in UTF-8 without
> any problems.
>
> Did I make myself clear now?

You made yourself clear the first time.  What I don't understand is, why
do you think this is a good idea, because in my view it clearly isn't.

So suppose we lie about the buffer content and say it's "abcde xyz".
Then the server sends a diagnostic saying "found unexpected space
character at column 6".  What sense does it make to the user?

Even worse, imagine we then request instructions to reformat the buffer.
Suppose that the replacement "abcde xyz" -> "abcde\nxyz" is meaningful
in our language but the replacement "abcde\201xyz" -> "abcde\nxyz" is
dangerous.  Do we want to get into this kind of trouble?