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

[Eli Zaretskii]

> From: Augusto Stoffel <arstoffel@gmail.com>
> Cc: joaotavora@gmail.com,  61726@debbugs.gnu.org
> Date: Fri, 24 Feb 2023 16:52:27 +0100
> 
> >    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?

How can that happen?  Raw bytes can be in comments and in strings, and
basically nowhere else in a program.  How would the server decide that
a space is not valid in these contexts?

> 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?

"Dangerous" in what way?

And your objections/fears seem to circle around the special traits of
the SPC character, so what if instead of SPC we use U+FFFD?