bug#21207: 25.0.50; Cursor position behaves unpredictably on the 'display text property

[Eli Zaretskii]

> Date: Fri, 7 Aug 2015 16:07:27 +0100
> From: Artur Malabarba <bruce.connor.am@gmail.com>
> 
> 1. Type `single line' into an empty buffer, and place the cursor at the space.
> 2. Hit M-: and evaluate the following snippet
>     (add-text-properties (point) (1+ (point)) '(display "\n"))
> 3. When the space in the middle gets "turned" into a newline, the
> cursor is left where it was (at the fake end of the first line, right
> after the word `single').
> 4. Now follow the same steps on a new buffer, but evalate this instead:
> (add-text-properties (point) (1+ (point)) '(display "\n------"))
> 5. This time, the cursor will be moved down to the start of the second
> "fake" line (right before the `-----'). Furthermore, it is impossible
> to place it at the position we had in item 3, it just jumps straight
> from the first `e' to the first `-', skipping the actual newline char.
> 
> If I can place the cursor on the newline in the first scenario, why
> can't I do so in the second?

Because we have special support for cursor positioning on display
strings that end in a newline (AFAIR, since some packages that change
how a newline is displayed needed that).

> Is there a way around this?

Why do you need it?  What is your real-life use case?

> I tried adding a '(cursor t) property to the "\n" substring, but
> nothing changed.

You cannot put a 'cursor' property on a newline, because a newline
leaves no glyphs on display.  To be effective, the 'cursor' property
needs to be placed on a character that produces some glyph.