bug-gnu-emacs
[Top][All Lists]
Advanced

[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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]