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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: 19200@debbugs.gnu.org, michael_heerdegen@web.de, jonas@bernoul.li
> Date: Mon, 21 Mar 2016 16:43:21 -0400
> 
> > Can someone tell me why you think point adjustment has anything to do
> > with the original report for this bug?  Because I fail to see any
> > connection; maybe I'm missing something.
> 
> > What I see is that vertical-motion, called by next-line's subroutines,
> > ends up at position 5, because when it tries to get to column zero, it
> > skips the invisible text between positions 3 and 5.  It stops at 5
> > because the function called to move to the goal column can only move
> > within a single display line.  IOW, this is a simple artifact of the
> > implementation of vertical-motion.
> 
> No, it's OK for vertical-motion to move to position 5.

OK, then I won't install that change.

> But adjust_point_for_property should move it back to position
> 3 (because that still ends up being a forward motion, when compared to
> the original point position, and it is in a "less-invisible" spot).

Your original report says:

  3. M-: (point) RET

    This should say 3 (where get-pos-property says it's not invisible)
    but returns 5 (where get-pos-property says it is invisible)!

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.

So what exactly is this bug about?