[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#61726: [PATCH] Eglot: Support positionEncoding capability
From: |
Eli Zaretskii |
Subject: |
bug#61726: [PATCH] Eglot: Support positionEncoding capability |
Date: |
Fri, 24 Feb 2023 15:34:05 +0200 |
> 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.
> and `json-serialize' rightfully emits an error.
There's no "rightfully" here. It's our decision to signal an error in
this case. Substituting some innocent character for the unencodable
ones would be an entirely legitimate alternative.
> So there's nothing Eglot can do to cope.
I'm talking about Emacs as a whole. Eglot shouldn't second-guess what
we might decide some day, definitely not in areas that are not
specific to Eglot, such as JSON.
> It also should not, IMO, because we don't know how the server will
> respond, and we must trust the server when it tell us to do
> destructive operations like adding or deleting text.
See above: replacing problematic characters would also solve this
problem. Some other applications out there actually behave like that.
- bug#61726: [PATCH] Eglot: Support positionEncoding capability, (continued)
- 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, 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 <=
- 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, 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