GNU bug report logs - #68900
29.1; Inconsistent Cursor Behavior when Executed as Lisp Code vs. Run by Key Binding

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jaft <jaft.r <at> outlook.com>
Cc: 68900 <at> debbugs.gnu.org
Subject: bug#68900: 29.1; Inconsistent Cursor Behavior when Executed as Lisp Code vs. Run by Key Binding
Date: Sat, 03 Feb 2024 09:31:01 +0200

tags 68900 notabug
thanks

> Date: Fri, 02 Feb 2024 16:47:57 -0600
> From: Jaft <jaft.r <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.