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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: João Távora <joaotavora <at> gmail.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#61726: closed ([PATCH] Eglot: Support positionEncoding
 capability)
Date: Mon, 27 Feb 2023 11:14:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Mon, 27 Feb 2023 11:15:00 +0000
with message-id <CALDnm53wKeQC-+kxMeVOinKeNKerwmfA6=-xs0v0EvGqCm=nLg <at> mail.gmail.com>
and subject line Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability
has caused the debbugs.gnu.org bug report #61726,
regarding [PATCH] Eglot: Support positionEncoding capability
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
61726: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61726
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Eglot: Support positionEncoding capability
Date: Thu, 23 Feb 2023 09:05:35 +0100

[Message part 3 (text/plain, inline)]

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 expresses Eglot's preferences as counting character offsets, then
byte offsets, then the UTF-16 nonsense, in that order.

I would also suggest preparing the stage to eventually make
`eglot-current-column-function' and `eglot-move-to-column-function'
obsolete.  For that, I suggest renaming

- eglot-current-column -> eglot--current-column-utf-32
- eglot-lsp-abiding-column -> eglot--current-columns-utf-16
- eglot-move-to-column -> eglot--move-to-columns-utf-32
- eglot-move-to-lsp-abiding-column -> eglot--move-to-columns-utf-16

and then making the old names obsolete aliases of the new names.

(I have tested the utf-32 case superficially, and not at all the utf-8.
So this is a RFC.)

[0001-lisp-progmodes-eglot.el-Support-positionEncoding-cap.patch (text/patch, attachment)]

[Message part 5 (text/plain, inline)]

PS: João, since you may have had trouble receiving some emails, did you
notice bug#58141?

[Message part 6 (message/rfc822, inline)]

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, 61726-done <at> debbugs.gnu.org
Cc: arstoffel <at> gmail.com
Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability
Date: Mon, 27 Feb 2023 11:15:00 +0000

On Sun, Feb 26, 2023 at 3:37 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: João Távora <joaotavora <at> gmail.com>
> > Cc: arstoffel <at> gmail.com,  61726 <at> debbugs.gnu.org
> > Date: Sun, 26 Feb 2023 15:15:57 +0000
> >
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> >
> > >> But as I said this is just a nit.
> > >
> > > I made one more fix.
> >
> > FTR, I think it's way worse now. The function variable has no clear
> > protocol: it's very odd to state its return type as number of code units
> > _or_ bytes _or_ code points.  A good docstring for such a variable notes
> > that, for any buffer position, a plugged-in function must return the
> > same _type_ but may return a different _value_ to match the
> > unit-counting strategy being used by the LSP server.
>
> It cannot return the same value,. it must return a value in the same
> units as its opposite.

I wrote "return the same _type_ but may return a different _value_".

The doc string says:
>
>   This is the inverse of `eglot-move-to-linepos-function' (which see).
>   It is a function of no arguments returning the number of code units
>   or bytes or codepoints corresponding to the current position of point,
>   relative to line beginning, as expected by the function that is the
>   value of `eglot-move-to-linepos-function'.")
>
> Note the last sentence.

Yes, I understand the intention.  That's a good detail, to state that
when that other function is fed the return value of this one, position
should remain unaltered.  I just did that.

> It's your package, so feel free to make any changes you like.

Done, and closing. We can deal with the `line-beginning-position` thing
afterwards.  It's only tangentially related to this encoding-supporting feature.

Previous Next

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