bug#8627: 24.0.50: cursor property behaves irregularly in before-strings

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 04 Dec 2021 22:44:50 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 8627@debbugs.gnu.org, aker@pitt.edu
> 
> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Cc: Alp Aker <aker@pitt.edu>,  8627@debbugs.gnu.org
> > Date: Sat, 04 Dec 2021 21:22:44 +0100
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > > This cannot possibly work, not without rewriting the Emacs display
> > > engine in ways I don't intend to.  Quite simply, you cannot put the
> > > `cursor' property on a newline that belongs to a string, because a
> > > newline, obviously, doesn't have a graphic representation (a glyph) on
> > > the screen, it just causes Emacs to continue drawing on the next
> > > screen line.
> > 
> > [...]
> > 
> > > I will eventually update the documentation with this caveat.
> > 
> > This was ten years ago -- I didn't check whether the documentation has
> > been updated, but there doesn't seem to be anything more to do here than
> > that?
> 
> I promised to fix at least some of the behavior, but never did.  I
> will take a look soon.

I took a look.  The code works correctly: since the before-string
leaves the buffer position visible, Emacs by default places the cursor
there, and a non-nil value of the 'cursor' property cannot override
this basic behavior.  If Emacs 23 behaved differently, it was a bug in
Emacs 23.  By contrast, when the value of 'cursor' is an integer, then
the cursor is placed on that character even if the corresponding
buffer position is visible.  Which is what Emacs now does.

So I've now documented these caveats, including the one wrt newline
characters, and I'm finally marking this bug done.