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

Previous Next

Full log

Message #206 received at 61726 <at> debbugs.gnu.org (full text, mbox):

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

> That's understandable as lsp-abiding has to measure the length in
> bytes of a number of codepoints every time it does one of
> the iterations of the binary search.  Position-bytes doesn't quite work
> there (I can't remember why). It's quite faster than it's linear search
> cousin.
>
> So comparing those two doesn't make sense.

The linear cousin of "lsp-abiding" is very similar to the
function that Eli wrote:

(defun eglot-move-to-lsp-abiding-column-linearly (column)
  "Move to COLUMN as computed using the LSP `utf-16' criterion."
  (let* ((bol (line-beginning-position))
	 (goal-char (+ bol column))
	 (eol (line-end-position)))
    (goto-char bol)
    (while (and (< (point) goal-char)
		(< (point) eol))
      (if (<= #x010000 (char-after) #x10ffff)
	  (setq goal-char (1- goal-char)))
      (forward-char 1))))

It would be very hard to believe they have different performance
characteristics.  In fact, in some hastily done tests, I get the
following relative running times:

eglot-move-to-colum: 1.0
eglot-move-to-lsp-abiding-column-linearly: 8.4
eglot-move-to-bytewise-column: 8.0
eglot-move-to-lsp-abiding-column: 14.4

Previous Next

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