bug#54488: 29.0.50; move-to-column/overlay-related regression in latest master, perhaps 28?

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: João Távora <joaotavora@gmail.com>
>> Date: Wed, 23 Mar 2022 01:11:21 +0000
>> Cc: Eli Zaretskii <eliz@gnu.org>, 54488@debbugs.gnu.org
>> 
>>  Tabs?
>> 
>> Aha! yup.  This idea won't fly.  Thanks, Dmitry, I was about to push that 
>> happily, but people definitely use tabs in their source code.  
>
> How do you know to which column to move when tabs are involved?  If
> clangd assumes a tab is at a multiple of 8, and the user has tab-width
> customized to a different value, you will end up in a wrong place
> anyway.  So this case should already cause problems, and if not,
> there's some code somewhere that handles it; let it handle it now with
> forward-char as well.

As I explained before, move-to-column is only used to obtain an upper
bound of a (binary) search backwards.  That search is for the
"LSP-abiding" column, which is tricky and based on UTF-16 code units
even though the file is usually UTF-8 encoded.  The gory details are all
in this issue https://github.com/joaotavora/eglot/pull/125 from 2018.

So if I start using forward-char, my upper bound will be unnecessarily
conservative.  The whole thing won't be wrong but slower.  And because
there can be very many diagnostics and things being annotated in
positions, it can make a difference.  I benchmarked it at the time.

I also think you're supposed to agree with the LSP server about
tab-width and stuff.  I just keep my tabs at 8 like They intended and I
don't have that problem, because at least clangd correctly assumes that
default.

João

PS: I do invite you to read that old Eglot issue.  Since you're an
expert on coding system conversion, maybe you know of a better, faster
way to find the correct LSPish column in an Emacs buffer.  Maybe the
whole search idea is completely overwrought.