Re: Odd behavior when moving point over invisible text

[Eli Zaretskii <eliz@gnu.org>]

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 05 Jun 2023 02:09:53 -0500
> 
> The reason I'm looking into your report was because I thought it 
> might be related to a known bug in indent.c:check_display_width() 

It isn't.

> I looked around in the code a bit for your bug. 
> cmds.c:Fforward_char() just calls move_point(), which in turn 
> looks like it boils down to calling intervals.c:set_point(), which 
> gets us to set_point_both() and that appears to finally be where 
> some interesting action starts.  So is there a call to 
> scan_for_column(), or something else that gets us to 
> check_display_width(), somewhere within set_point_both() in the 
> call stack?  Maybe?  I don't yet know.

No, those are not relevant.  What happens here is the feature known as
"point-adjustment" kicks in, and attempts to move point out of
invisible text.  See disable-point-adjustment for more details.

> I also don't know why `forward-char' is behaving differently in 
> your reproduction recipe when called via `C-f' versus other ways. 
> That's quite odd IMHO!  Both `M-x forward-char' and direct 
> minibuffer evaluation of `(forward-char 1)' result in point 
> staying on the first dot, just as you said, which is position 15 
> in the buffer.  Whereas typing `C-f' moves point over the whole 
> ellipsis and goes to position 28 in the buffer.  What's up with 
> that?  There doesn't seem to be any advice added to anything by 
> outline.el (disclaimer: I'm not very familiar with the advice 
> mechanism in Emacs).  For example, calling `(ad-has-any-advice 
> 'forward-char)' within the reproduction buffer returns nil.

It's a bug.  Bugs are often odd.  The point-adjustment feature needs
to record the previous position of point, to know in which direction
to move it in order to exit the invisible area: if point moved to a
larger buffer position and entered invisible text, point-adjustment
wants to move it further forward; if it moved towards lower position,
point-adjustment wants to move it back.  The bug was that last point
position was recorded in a global variable, and M-x enters
recursive-edit, which clobbered that variable's value with the value
from the minibuffer.