[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Odd behavior when moving point over invisible text
From: |
Eli Zaretskii |
Subject: |
Re: Odd behavior when moving point over invisible text |
Date: |
Mon, 05 Jun 2023 16:05:31 +0300 |
> 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.