bug#21368: 25.0.50; Core navigation commands fail in a multi-line intangible text with fringe

[Eli Zaretskii <eliz@gnu.org>]

> From: Vitalie Spinu <spinuvit@gmail.com>
> Date: Fri, 28 Aug 2015 17:46:54 +0200
> 
>  (defun insert-with-fringe ()
>    (insert
>     "      "
>     (concat
>      (propertize "fringe" 'display (list 'left-fringe 'filled-square font-lock-doc-face))
>      (propertize "dummy" 'display "AAA\n" 'font-lock-face font-lock-doc-face))
>     "some more text")
>    (previous-line))
> 
> Execute (insert-with-fringe). It should position the cursor just in front of the
> "AAA" string.
> 
> Now (backward-char 1) or (goto-char (1- (point))) don't have any effect, and
> (previous-line) goes to bol instead of the previous line.

The first two do work, you just need to invoke backward-char twice to
see the cursor move.  But "C-x =" will show you that backward-char did
move even after the first time.  The cursor doesn't move the first
time because you have buffer positions covered by a display property
that is displayed on the fringe, and the first backward-char moves
into those buffer positions.  This is nothing new: you can see it
whenever you use the fringe property without all the rest in this
scenario.  So this part of the behavior is not a bug.

The behavior of previous-line is indeed a bug, and it is hard to fix.

> It has to do with the trailing "\n" in "AAA\n". If that new line is removed,
> everything works as expected.

No, it's because you have 2 consecutive display properties, _and_ the
second one ends in a newline.  There's code in vertical-motion that
attempts to avoid the lossage when a display property includes
newlines, but the fringe display property before that defeats that
code.

Is there some important real-life use case that needs this to work?
Otherwise, I'm inclined to leave this alone.  After all, it's not a
catastrophe: the next call to previous-line will go to the line you
want.