GNU bug report logs - #9034
point adjustment (with invisible text) moves to the next line

Previous Next

Full log

Message #33 received at 9034 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 9034 <at> debbugs.gnu.org, dmitry.kurochkin <at> gmail.com
Subject: Re: bug#9034: point adjustment (with invisible text) moves to the
 next line
Date: Thu, 26 Aug 2021 18:46:37 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: dmitry.kurochkin <at> gmail.com,  9034 <at> debbugs.gnu.org
> Date: Thu, 26 Aug 2021 15:48:32 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > This code is chock-full of questionable heuristics, and in particular
> > tries to guess in which direction to move point out of the invisible
> > text.  The results are sometimes surprising.  The upside is that it
> > "mostly works".  But if someone can come up with a better heuristics,
> > I'm all ears.
> 
> Ah, right.  But...  the super-confusing thing about this is that we're
> not moving point in the buffer at all.

The original recipe moved from point-min to an end of a line.

> Just doing `M-: 4 RET' will result in this code adjusting point in
> the buffer.  Doing, for instance, `M-x foo RET' (where `foo' does
> nothing) does not result in this point movement.
> 
> So is `M-:' doing some weird thing in the original buffer to trigger
> this oddity?

Doing M-: in what part of the recipe?

Previous Next

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