Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability

From: Eli Zaretskii <[email-masked]>
Date: Sun, 26 Feb 2023 08:03:17 +0200

> From: Augusto Stoffel <[email-masked]>
> Cc: Eli Zaretskii <[email-masked]>,  [email-masked]
> Date: Sun, 26 Feb 2023 00:57:42 +0100
> 
> 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

The current version of eglot-move-to-lsp-abiding-column calls
encode-coding-region in the loop, which I guess is the main reason for
its being slower.