[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#61726: [PATCH] Eglot: Support positionEncoding capability
From: |
João Távora |
Subject: |
bug#61726: [PATCH] Eglot: Support positionEncoding capability |
Date: |
Fri, 24 Feb 2023 13:45:23 +0000 |
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
- bug#61726: [PATCH] Eglot: Support positionEncoding capability, (continued)
- bug#61726: [PATCH] Eglot: Support positionEncoding capability, João Távora, 2023/02/24
- bug#61726: [PATCH] Eglot: Support positionEncoding capability, Eli Zaretskii, 2023/02/24
- bug#61726: [PATCH] Eglot: Support positionEncoding capability, João Távora, 2023/02/24
- bug#61726: [PATCH] Eglot: Support positionEncoding capability, Eli Zaretskii, 2023/02/24
- bug#61726: [PATCH] Eglot: Support positionEncoding capability, Augusto Stoffel, 2023/02/24
- bug#61726: [PATCH] Eglot: Support positionEncoding capability, Augusto Stoffel, 2023/02/24
- bug#61726: [PATCH] Eglot: Support positionEncoding capability, Eli Zaretskii, 2023/02/24
- bug#61726: [PATCH] Eglot: Support positionEncoding capability, Augusto Stoffel, 2023/02/24
- bug#61726: [PATCH] Eglot: Support positionEncoding capability, João Távora, 2023/02/24
- bug#61726: [PATCH] Eglot: Support positionEncoding capability, Eli Zaretskii, 2023/02/24
- bug#61726: [PATCH] Eglot: Support positionEncoding capability,
João Távora <=
- bug#61726: [PATCH] Eglot: Support positionEncoding capability, Eli Zaretskii, 2023/02/24
- bug#61726: [PATCH] Eglot: Support positionEncoding capability, Augusto Stoffel, 2023/02/24
- bug#61726: [PATCH] Eglot: Support positionEncoding capability, Eli Zaretskii, 2023/02/24
- bug#61726: [PATCH] Eglot: Support positionEncoding capability, Augusto Stoffel, 2023/02/24
- bug#61726: [PATCH] Eglot: Support positionEncoding capability, Eli Zaretskii, 2023/02/24
- bug#61726: [PATCH] Eglot: Support positionEncoding capability, Augusto Stoffel, 2023/02/24
- bug#61726: [PATCH] Eglot: Support positionEncoding capability, Eli Zaretskii, 2023/02/24
- bug#61726: [PATCH] Eglot: Support positionEncoding capability, Augusto Stoffel, 2023/02/24
- bug#61726: [PATCH] Eglot: Support positionEncoding capability, João Távora, 2023/02/24
- bug#61726: [PATCH] Eglot: Support positionEncoding capability, Eli Zaretskii, 2023/02/25