[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#61726: [PATCH] Eglot: Support positionEncoding capability
From: |
Augusto Stoffel |
Subject: |
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@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.
- bug#61726: [PATCH] Eglot: Support positionEncoding capability, (continued)
- bug#61726: [PATCH] Eglot: Support positionEncoding capability, João Távora, 2023/02/26
- 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, 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/23
bug#61726: [PATCH] Eglot: Support positionEncoding capability, Felician Nemeth, 2023/02/23