GNU bug report logs - #61726
[PATCH] Eglot: Support positionEncoding capability

Previous Next

Full log

View this message in rfc822 format

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61726 <at> debbugs.gnu.org, joaotavora <at> gmail.com
Subject: bug#61726: [PATCH] Eglot: Support positionEncoding capability
Date: Fri, 24 Feb 2023 17:39:11 +0100

On Fri, 24 Feb 2023 at 18:01, Eli Zaretskii wrote:

>> From: Augusto Stoffel <arstoffel <at> gmail.com>
>> Cc: joaotavora <at> gmail.com,  61726 <at> 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?

If someone thinks this is a good and useful feature, of course they
could work on it.  I think the current behavior (json-serialize error)
is better because it sticks to the letter of the specs.

My point of view is very straightforward: you can have language servers;
you can have arbitrary bytes in your files and buffers; but you can't
always have both.  But I'm sure I've already communicated this, sorry
for the repetition.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.