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

["João Távora" <joaotavora@gmail.com>]

On Fri, Feb 24, 2023 at 1:34 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Augusto Stoffel <arstoffel@gmail.com>
> > Cc: joaotavora@gmail.com,  61726@debbugs.gnu.org
> > Date: Fri, 24 Feb 2023 13:35:37 +0100
> >
> > On Fri, 24 Feb 2023 at 14:16, Eli Zaretskii wrote:
> >
> > > 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.
> >
> > You can't even send or receive a message through the JSONRPC channel if
> > it's not valid UTF-8

> That's because we _decided_ to behave like that.  A decision that is
> not carved in stone.

At least or LSP, it seems it must be UTF-8:

  https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#contentPart

"... utf-8, which is the only encoding supported right now. If a
server or client
receives a header with a different encoding than utf-8 it should respond
with an error."

No problem with making jsonrpc.el support more encodings, but for LSP
it must be UTF-8.

I don't see how this is relevant to the code-point counting problem here,
though.

João