GNU bug report logs - #19200
Point adjustment moves *into* invisible text

Previous Next

Full log

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, jonas <at> bernoul.li, 19200 <at> debbugs.gnu.org
Subject: Re: bug#19200: Point adjustemnt moves *into* invisible text
Date: Tue, 22 Mar 2016 14:36:10 -0400

> But I'm sure you know very well that point adjustment code doesn't use
> get-pos-property, it uses get-char-property-and-overlay, and the
> latter says position 5 is visible.  There was an attempt to use
> get-pos-property in that code, but it backfired and was disabled.

No, I didn't remember (and still don't actually, tho I now see the
corresponding comments and #if0 in the code).

But that change only affects the decision of what we consider as the
boundaries of a chunk of invisible text (so it makes no difference in
the present test case where there is no such ambiguity).

Once those boundaries are found, we do use Fget_pos_property to decide
which boundary to go to.

> So what exactly is this bug about?

There are 2 odd behaviors:
- point adjustment doesn't bring us to position 3 after C-n
- M-: (point) has the side-effect of bringing us to position 3
  My guess here is that after the M-: command, at the end of
  command_loop_1, last_point_position refers to a position in another
  buffer (i.e. in the minibuffer), so it thinks there was a movement and
  hence re-runs adjust_point_for_property, which this time gets it right.


        Stefan

Previous Next

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