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 13:01:16 +0100
> 
> On Fri, 24 Feb 2023 at 13:27, Eli Zaretskii wrote:
> 
> >> > As discussed, position-bytes is incorrect.  You should instead do
> >> > something like
> >> >
> >> >   (length (encode-coding-string
> >> >            (buffer-substring-no-properties (point)
> >> >                                            (line-beginning-position))
> >> >            'utf-8-unix t))
> >> 
> >> But it is incorrect only if the buffer contains characters outside of
> >> the Unicode range, right?  If that happens, we already lost, because a
> >> few steps later we will serialize the buffer text as JSON to send it to
> >> the server:
> >
> > Why should one part of the code depend on what another part does?  In
> > my book, each part should do its job, and do it right.
> 
> Arguably both implementations are wrong, and the correct one should
> produce an error if the buffer substring cannot be converted to valid
> UTF-8.

You assume that the characters that aren't encodable in UTF-8 somehow
invalidate the results produced by the LSP?  But that is not
necessarily true, it depends on the context.  IOW, this is not the
problem eglot.el should solve, and I'm not sure that signaling an
error is the correct reaction to this situation.  It is basically the
problem of the user and/or the major mode.  Eglot should do its best
to cope, and leave the rest to the user.

> Between two “wrong” but perfectly functional implementations, I'd choose
> the more efficient one, because efficiency actually matters in this
> case.  So which one is more efficient?

I don't know, and I don't think efficiency is the main concern here.
The main concern, from my POV, is exposing the internal representation
of buffer text to the outer world.  What if we decide to change the
internal representation at some future date?  It already happened,
twice, in Emacs history; it can happen again, even though its
unlikely.