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

Previous Next

Full log

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

From: João Távora <joaotavora <at> gmail.com>
To: Augusto Stoffel <arstoffel <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: Sat, 25 Feb 2023 23:16:38 +0000

On Sat, Feb 25, 2023 at 10:34 PM Augusto Stoffel <arstoffel <at> gmail.com> wrote:
>
> On Sat, 25 Feb 2023 at 22:13, João Távora wrote:
>
> > 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?
>
> Funnily, in the quick tests I made, Eli's function seems twice as fast
> as "lsp-abiding".

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.  I meant comparing a
linear version of the utf-8 function to a binary-searching version of
the same utf-8 function.  If that even makes sense here: I'm not sure it
does because I haven't followed the details of the problem.

João

Previous Next

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