bug#61726: [PATCH] Eglot: Support positionEncoding capability

["João Távora" <joaotavora@gmail.com>]

On Fri, Feb 24, 2023 at 11:47 AM Augusto Stoffel <arstoffel@gmail.com> wrote:
>
> On Fri, 24 Feb 2023 at 11:18, João Távora wrote:
>
> > The capability is stored in the server object and reflects in the buffer-local
> > variable which will be restored when the session ends.  I don't see
> > any problem with that.
>
> No problem, let's use your approach then.
>
> >> I suggest you to guard against future headaches.  We can store the
> >> offset functions in two slots of the server class if you don't like to
> >> traverse the capabilities plist each time.
> >
> > No, this is exactly the type of complexity that I strive to avoid in Eglot,
> > especially when the added value is small.
>
> You see how “complexity” can be a subjective perception...  To me,
> entangling things is a hallmark of complexity, and you are entangling
> server information with buffer information here.  OTOH, adding a slot
> that is set in 1 place and read in 1 place doesn't feel like complexity
> at all to me.

Very true, it's subjective.  But both of our approaches are using
multiple levels of removal from the source of truth.  The source of
truth is in the server, then it's cached in eglot--capabilities.  Then
I propose another level, cache it a buffer-local value, and you
also propose another level, cache it an additional slot of
the server.

And don't forget that the "server" is _also_ hiding behind an
indirection, the eglot--current-server function and buffer
variable.

What IMO makes your solution more complex is that the new alternate
place of caching will not cause eglot-move-to-column-function and
eglot-current-column-function to be deleted.  We can't delete, even
if we wanted to, because of backward compatibility.  If you could,
I would agree that our two solutions are of similar complexity.  But
that's not the reality.

João