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: João Távora
Subject: 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
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: João Távora <joaotavora@gmail.com>
>> Date: Tue, 22 Mar 2022 21:05:09 +0000
>> Cc: Dmitry Gutov <dgutov@yandex.ru>, 54488@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





reply via email to

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