[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#61726: closed ([PATCH] Eglot: Support positionEncoding capability)

From: GNU bug Tracking System
Subject: bug#61726: closed ([PATCH] Eglot: Support positionEncoding capability)
Date: Mon, 27 Feb 2023 11:14:02 +0000

Your message dated Mon, 27 Feb 2023 11:15:00 +0000
with message-id 
and subject line Re: bug#61726: [PATCH] Eglot: Support positionEncoding 
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

61726: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61726
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: [PATCH] Eglot: Support positionEncoding capability Date: Thu, 23 Feb 2023 09:05:35 +0100
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

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.)

Attachment: 0001-lisp-progmodes-eglot.el-Support-positionEncoding-cap.patch
Description: Text Data

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

--- End Message ---
--- Begin Message --- 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@gnu.org> wrote:
> > From: João Távora <joaotavora@gmail.com>
> > Cc: arstoffel@gmail.com,  61726@debbugs.gnu.org
> > Date: Sun, 26 Feb 2023 15:15:57 +0000
> >
> > Eli Zaretskii <eliz@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.

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]