GNU bug report logs - #61726
[PATCH] Eglot: Support positionEncoding capability

Previous Next

Full log

Message #116 received at 61726 <at> debbugs.gnu.org (full text, mbox):

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61726 <at> debbugs.gnu.org, joaotavora <at> gmail.com
Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability
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, and `json-serialize' rightfully emits an error.
So there's nothing Eglot can do to cope.  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.

> I don't know, and I don't think efficiency is the main concern here.

Okay, but João expressed his concerned with efficiency 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.

Here you have a good point.  LSP got into this mess in the first place
because of exposure of JavaScript internals.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.