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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: João Távora <joaotavora <at> gmail.com>
Cc: 54488 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: Re: bug#54488: 29.0.50; move-to-column/overlay-related regression in
 latest master, perhaps 28?
Date: Wed, 23 Mar 2022 16:21:00 +0200

> From: João Távora <joaotavora <at> gmail.com>
> Date: Wed, 23 Mar 2022 11:08:55 +0000
> Cc: Dmitry Gutov <dgutov <at> yandex.ru>, 54488 <at> debbugs.gnu.org
> 
>  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.
> 
> These issues may give additional context about the need for this particular
> move-to-column dance.
> 
> https://github.com/joaotavora/eglot/issues/125 (the one I gave you already) 
> https://github.com/joaotavora/eglot/issues/124 (the bug that prompted the 125 fix)
> https://github.com/joaotavora/eglot/issues/361 (an easier to grasp manifestation of the problem) 

I see that you had problems reconciling the LSP idea of "columns" with
that of Emacs.  If LSP indeed works in UTF-16 (I don't know, but I
have no reason to doubt that), then I think your solution is decent,
although actually encoding stuff could be overhead: after all, whether
a given codepoint takes 1 or 2 UTF-16 code units can be easily
established by looking at the codepoints themselves.  But that's an
optimization.

> But I still do think there was a regression in Emacs somewhere: I've described an
> unequivocal reproduction recipe, just not something that can be shared among us, 
> due to technical (or licensing) hurdles.

It is this single issue that puzzles me.  AFAIU, you are saying that
in some situation, calling move-to-column causes point to be set
outside of the current accessible region of the buffer, which I cannot
understand how it can happen.  Everything I tried yields the same
correct result: move-to-column always stops at the end of the
accessible portion of the buffer, no matter what ridiculously large
argument I pass to it.  And the change which we think caused this
problem just makes the column values for some situation smaller or
larger, that's all, so it "just" affects the argument to
move-to-column.

Previous Next

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