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

Previous Next

Package: emacs;

Reported by: Augusto Stoffel <arstoffel <at> gmail.com>

Date: Thu, 23 Feb 2023 08:06:01 UTC

Severity: normal

Tags: patch

Done: João Távora <joaotavora <at> gmail.com>

Bug is archived. No further changes may be made.

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 07:31:34 +0200
> From: João Távora <joaotavora <at> gmail.com>
> Cc: Augusto Stoffel <arstoffel <at> gmail.com>,  61726 <at> debbugs.gnu.org
> Date: Sat, 25 Feb 2023 22:13:29 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Augusto Stoffel <arstoffel <at> gmail.com>
> >> Cc: joaotavora <at> gmail.com,  61726 <at> debbugs.gnu.org
> >> Date: Sat, 25 Feb 2023 15:14:06 +0100
> >> 
> >> On Sat, 25 Feb 2023 at 15:47, Eli Zaretskii wrote:
> >> 
> >> >> > Can you please humor me and implement eglot-bytewise-column like that?
> >> >> 
> >> >> I would be glad to do that, but unfortunately I'd have to ask your
> >> >> advice as to how to make the corresponding adaptation of
> >> >> eglot-move-to-bytewise-column.
> >>          ^^^^^^^
> >
> > Sorry.  Here:
> >
> >   (defun eglot-move-to-bytewise-column (column)
> >     "Move to COLUMN as computed using the LSP `utf-8' criterion."
> >     (let* ((bol (line-beginning-position))
> > 	   (goal-byte (+ (position-bytes bol) column))
> > 	   (eol (line-end-position)))
> >       (goto-char bol)
> >       (while (and (< (position-bytes (point)) goal-byte)
> > 		  (< (point) eol))
> > 	(if (>= (char-after) #x3fff80)  ; raw bytes take 2 bytes in the buffer
> > 	    (setq goal-byte (1+ goal-byte)))
> > 	(forward-char 1))))
> 
> In eglot-move-to-lsp-abiding-column (the utf-16 sibling of this
> function) we use a binary search instead of a linear search.  I remember
> measuring a visible improvement.  I'm not sure the conditions are
> exactly the same with this one.  Could/should we do the same here?

Fine by me, but optimizing a method that is not yet used sounds a bit
premature, no?  I won't object, though.




This bug report was last modified 2 years and 138 days ago.

Previous Next


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