bug#19200: Point adjustemnt moves *into* invisible text

[Stefan Monnier <monnier@iro.umontreal.ca>]

> 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