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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: João Távora <joaotavora <at> gmail.com>
Cc: 61726 <at> debbugs.gnu.org, arstoffel <at> gmail.com
Subject: bug#61726: [PATCH] Eglot: Support positionEncoding capability
Date: Sun, 26 Feb 2023 17:37:42 +0200

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

> I haven't reverted to avoid a commit war, and because I'm a bit weary of
> this bug.  I leave a patch for consideration and for the record, feel
> free to ignore it.

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

Previous Next

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