Ahhh; you know, I was looking at Invisible Text (GNU Emacs Lisp Reference Manual) but missed the end where it talks about Adjusting Point. While I'd been wondering if "relocat[ing] point to the other side of the text" might be affecting this, I don't think I'd grasped that it'd be after the command runs, either.
Thanks so much for clarifying it (and pointing out where to look, in the documentation). Do I need to close this, in any way, or was you tagging it as "notabug" sufficient?

| 
| 
|  | 
Invisible Text (GNU Emacs Lisp Reference Manual)

Invisible Text (GNU Emacs Lisp Reference Manual)
 |

 |

 |




    On Saturday, February 3, 2024 at 01:31:09 AM CST, Eli Zaretskii <eliz@gnu.org> wrote:  
 
 tags 68900 notabug
thanks

> Date: Fri, 02 Feb 2024 16:47:57 -0600
> From: Jaft <jaft.r@outlook.com>
> 
> This is where the inconsistent behavior is: if we M-: (forward-line -1)
> or M-: (previous-line) and, then, M-: (point), we'll get what (I would
> think) we'd expect: point 72, the point of the beginning of the second
> line.
> 
> BUT, if we do the above via key-binding – i.e. if, from point 145, we
> press C-p to get to the line above – and, then, run M-: (point), we
> get back the number 1.

This is the point-adjustment feature in action: it moves point out of
the invisible text in the direction of the last movement.  If you want
to disable it, set global-disable-point-adjustment to a non-nil value;
if you want to disable that temporarily in a Lisp program, set
disable-point-adjustment non-nil before invoking some cursor-movement
command.  In your recipe, if you set global-disable-point-adjustment
non-nil, the behavior of previous-line, whether via M-: or C-p, will
be consistent: it will end at position 72.

This is not a bug, but the intended behavior.  Read all about it in
the "Adjusting Point" section of the ELisp manual.  Admittedly, this
feature can sometimes cause surprising behavior.