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

[Eli Zaretskii <eliz@gnu.org>]

> 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.

>  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.  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?

>  >  Why do you have to use move-to-column instead of forward-char?
>  > 
>  > I don't remember! Is it exactly equivalent if you're standing in the beginning of the line? 
> 
>  Yes, if you have only text in the buffer (no images etc.).
> 
> Hmmm, it's interesting. Maybe I should just switch to that. Seems to fix it. Until someone adds images to the
> source code i suppose. What's your "etc"?

Any "display element" that is not text, like xwidgets.