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

Previous Next

Full log

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

From: João Távora <joaotavora <at> gmail.com>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: 61726 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability
Date: Fri, 24 Feb 2023 12:55:18 +0000

On Fri, Feb 24, 2023 at 12:35 PM Augusto Stoffel <arstoffel <at> gmail.com> wrote:
>
> 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.

It's _a_ concern.  And so is clarity.  I don't want to have
unneeded late-binding.  These functions are called very
often and the continuous advance of LSP with more features
like say, server-calculated fontification will make us
rely even more heavily on them, almost like we rely on a
fast goto-char.

João

Previous Next

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