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

[Eli Zaretskii]

> From: Augusto Stoffel <arstoffel@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  61726@debbugs.gnu.org
> Date: Fri, 24 Feb 2023 15:54:46 +0100
> 
> On Fri, 24 Feb 2023 at 13:45, João Távora wrote:
> 
> > I don't see how this is relevant to the code-point counting problem here,
> > though.
> 
> The relevance is in how the offset-counting function should proceed when
> the buffer is not UTF-8 encodable:
> 
> - My patch has a garbage-in garbage-out behavior.
> 
> - Eli made a suggestion he deems more correct, but is more expensive.

It is not more expensive.  The underlying functions we call are
already capable of producing replacements instead of characters that
cannot be encoded in UTF-8.  We just don't use those capabilities in
json.c because some of us had strong feelings about signaling an error
in these situations.

>   Since JSON must be UTF-8 encoded for data exchange purposes, I don't
>   see the benefit, and in fact I consider this option just a different
>   choice of garbage-in garbage-out behavior.

The benefit could be that Emacs is more lenient in face of such
situations, and doesn't signal errors from very low-level code which
has no idea about the context.

> - A third option is to make the function throw an error.  However, if
>   the buffer is not UTF-8 encodable, we already get an error from
>   json-serialize, because it doesn't let you generate invalid JSON:
> 
>     (progn
>      (insert ?" (max-char) ?")
>      (json-serialize (buffer-substring-no-properties (pos-bol)
>      (pos-eol))))
> 
>      ⇒ Debugger entered--Lisp error: (wrong-type-argument utf-8-string-p "    
>  \"\377\"")

What if json-serialize stops signaling an error at some point, and
instead uses the replacement mechanism I mentioned above?