bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#54488: 29.0.50; move-to-column/overlay-related regression in latest


From: Eli Zaretskii
Subject: 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@gmail.com>
> Date: Wed, 23 Mar 2022 11:08:55 +0000
> Cc: Dmitry Gutov <dgutov@yandex.ru>, 54488@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]