bug#35899: 26.1; move-beginning-of-line sometimes does not move to beginning of line

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Cc: 35899@debbugs.gnu.org,  triska@metalevel.at
> Date: Sat, 22 Jun 2019 18:54:00 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > For starters, there's no bug-35899-hello.png, but I guess any image will do,
> 
> Sorry, I meant the "hello.png" attached to the OP (I tend to give
> bug-specific names locally), but indeed any image will do.
> 
> > so I used splash.png.  But then (move-beginning-of-line nil) moves to
> > the beginning of "def", which is not inside the image.  What did I
> > miss?
> 
> Hmm, something a bit funny here: M-x move-beginning-of-line and M-:
> (move-beginning-of-line nil) go to the beginning of "def", but C-a
> (which is bound to move-beginning-of-line) goes onto the image (same as
> C-4 C-b).

It doesn't go into the image, it stops at the first character covered
by the display property.

> I guess the switch to minibuffer affects things somehow?

Probably; I didn't try to dig into this.  I don't really understand
the significance of this example or what is it that we are requested
to do.  In this case "the beginning of line" is not well defined.

> But neither of these behaviours seems to be "disregarding" the newlines
> that the "image rests on", i.e., it's different from what happens
> without the newlines:
> 
> (let ((img (create-image "splash.png")))
>   (insert "abc")
>   (insert-image img "foo bar baz")
>   (insert "def"))

I don't object to the proposed change of documentation, although I
don't see how it makes the issue significantly more clear.  Point
movement in the presence of images that conceal newlines is tricky to
describe in any terms but those of how the display engine works.

Thanks.