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

Previous Next

Full log

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

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
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 10:04:40 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: João Távora <joaotavora <at> gmail.com>
>> Date: Tue, 22 Mar 2022 21:05:09 +0000
>> Cc: Dmitry Gutov <dgutov <at> yandex.ru>, 54488 <at> debbugs.gnu.org
>> 
>>  >  >      do (condition-case eob-err
>>  >  >             (forward-char (/ (if (> diff 0) (1+ diff) (1- diff)) 2))
>>  >  >           (end-of-buffer (cl-return eob-err))))))
>> 
>>  I don't see how this could cause the problem you describe, but please
>>  note that encode-coding-region generally changes the text in the
>>  region, so maybe what you consider to be outside the restriction
>>  isn't?
>> 
>> I passed it t as the last argument, so it should be non-destructive to the buffer.
>
> But you do that in a loop AFAIU, so one iteration could affect the
> next ones.  But I'm just hand-waving here.

I'm not doing it a loop for destructive effect.  I'm doing it for
measuring.  If you're interested in the full 2018 story, it's
https://github.com/joaotavora/eglot/pull/125. 
 
>>  Anyway, do you have an example of text in which this function causes
>>  point to return such problematic values?
>> 
>> The only example I have is the one I described already, as best as I could. A user reported it to me, i installed
>> clangd, and I reproduced it very easily.
>> 
>> If you could consider installing clangd then running that ready-to-use recipe, I'd venture to say it's the easiest
>> way for you to understand the problem.
>
> Sorry, not going to happen.

Is it because it's a non GPL server, or just because you don't like to
install LSP servers?  Other LSP servers will probably have the same
problem.

> And I don't see why that would be necessary: the problem happens
> entirely in Emacs Lisp, so the only thing we need from clangd is its
> output that Emacs uses.  Can't you or someone collect that and include
> it in the recipe?

Actually, I do have that, and a LSP could be built that simply replays
those logs. But this is too complex.

I guess if you could point me to (your?) commit that changed the
behaviour in I can do the reproduction here and see the problem
myself, when I have time.

João

Previous Next

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