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

Previous Next

Full log

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

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Felician Nemeth <felician.nemeth <at> gmail.com>
Cc: 61726 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 João Távora <joaotavora <at> gmail.com>
Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability
Date: Thu, 23 Feb 2023 19:42:29 +0100

On Thu, 23 Feb 2023 at 18:01, Felician Nemeth wrote:

> Augusto Stoffel <arstoffel <at> gmail.com> writes:
>
>> Tags: patch
>>
>> There is a new LSP capability allowing the server and client to agree on
>> a way to count character offsets.  What do you think fo the attached
>> patch?
>
> It closes https://github.com/joaotavora/eglot/pull/916, hooray!
>
> I think the patch has a small bug.  With it, Eglot always negotiate the
> encoding with the server, but when the user sets
> eglot-current-column-function or eglot-move-to-column-function, the
> result of the negotiation is ignored, which might confuse the server.

This is intentional, so let's see if you agree with my rationale.

Currently, the point of eglot-{current-,move-to-}column-function is to
override the behavior of nonconforming servers.  There's no reason to
touch it if your server conforms 100% to the spec.  (Note that if you
update your nonconforming server and it now became conforming, then all
of a sudden you setup is guaranteed to be broken; you need to unset
those variables!)

With my patch, the purpose of these vars continues to be to override the
wrong behavior of a defective server.  So of course it should ignore the
result of the negotiation.

Moreover, I would like to mark eglot-{current-,move-to-}column-function
obsolete (preferably right now), so it can be removed entirely in a few
years. By then, there should be no excuse for nonconforming servers,
since they can use the positionEncoding protocol to stay away of the
UTF-16 nonsense.  Of course, if that proves a wrong assumption, we'll
just keep those vars around for longer.

What do you think?

> (In the long run, it might make sense to let the list of the offered
> encodings configurable.)

I don't think I understand why.  We would already be offering all 3
positionEncoding options.  The server can pick whatever they like and
we'll deal with it.  Everything should "just work", no need for
configuration.

Previous Next

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