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