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

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

[Markus Triska]

Please download hello.png with:

    $ wget https://www.metalevel.at/ei/hello.png

and then, starting Emacs with "emacs -Q", evaluate the following form:

    (progn
      (goto-char (point-min))
      (save-excursion (insert "\n"))
      (goto-char (+ (point) (cadr (insert-image-file "hello.png"))))
      (move-beginning-of-line nil))

This yields: 592, and does not move point to the beginning of the line.

However, the documentation of move-beginning-of-line includes:

   (If there’s an image in the line, this disregards newlines
   which are part of the text that the image rests on.)

Hence, I expect this to move to position 1. For comparison, when I press
C-a, it does move to position 1, as expected.

Would you please consider adjusting the function so that it behaves as
documented? Alternatively, could you please provide this feature in a
different way?

Thank you and all the best,
Markus

In GNU Emacs 26.1 (build 3, x86_64-pc-linux-gnu, X toolkit, Xaw scroll bars)
 of 2019-04-09 built on mt-laptop
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000

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

[Eli Zaretskii]

> From: Markus Triska <triska@metalevel.at>
> Date: Sat, 25 May 2019 15:31:57 +0200
> 
>     $ wget https://www.metalevel.at/ei/hello.png
> 
> and then, starting Emacs with "emacs -Q", evaluate the following form:
> 
>     (progn
>       (goto-char (point-min))
>       (save-excursion (insert "\n"))
>       (goto-char (+ (point) (cadr (insert-image-file "hello.png"))))
>       (move-beginning-of-line nil))
> 
> This yields: 592, and does not move point to the beginning of the line.
> 
> However, the documentation of move-beginning-of-line includes:
> 
>    (If there’s an image in the line, this disregards newlines
>    which are part of the text that the image rests on.)
> 
> Hence, I expect this to move to position 1. For comparison, when I press
> C-a, it does move to position 1, as expected.

"the text that the image rests on" refers to the text which is
"covered" by the display property, not the newlines in the binary data
that constitutes the image file's data.

> Would you please consider adjusting the function so that it behaves as
> documented?

This function works on the logical/physical lines, not on visual lines.

> Alternatively, could you please provide this feature in a different
> way?

I suggest to use beginning-of-visual-line instead.

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

[Noam Postavsky]

[-- Attachment #1: Type: text/plain, Size: 957 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> However, the documentation of move-beginning-of-line includes:
>> 
>>    (If there’s an image in the line, this disregards newlines
>>    which are part of the text that the image rests on.)
>> 
>> Hence, I expect this to move to position 1. For comparison, when I press
>> C-a, it does move to position 1, as expected.
>
> "the text that the image rests on" refers to the text which is
> "covered" by the display property, not the newlines in the binary data
> that constitutes the image file's data.

If I create an image which rests on some newlines like this:

    (let ((img (create-image "bug-35899-hello.png")))
      (insert "abc")
      (insert-image img "foo\nbar\nbaz")
      (insert "def"))

Then with point after "def", move-beginning-of-line stops "inside" the
image.  And I don't see anything in its code which would allow it to
skip the image.  Isn't this just a doc bug?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 3034 bytes --]

From f64d539780c0aa8e1a3322afa518eb768f468e16 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Fri, 21 Jun 2019 05:52:14 -0400
Subject: [PATCH] Clarify docs about line movement (Bug#35899)

* doc/lispref/positions.texi (Text Lines, Screen Lines): Add index
entries.
* lisp/simple.el (move-beginning-of-line): Remove incorrect mention of
images, and reference beginning-of-visual-line.
* src/editfns.c (Fline_beginning_position): Reference
`vertical-motion'.
---
 doc/lispref/positions.texi | 3 +++
 lisp/simple.el             | 8 ++++----
 src/editfns.c              | 3 ++-
 3 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/doc/lispref/positions.texi b/doc/lispref/positions.texi
index 7707793467..128685800f 100644
--- a/doc/lispref/positions.texi
+++ b/doc/lispref/positions.texi
@@ -332,6 +332,8 @@ Buffer End Motion
 @node Text Lines
 @subsection Motion by Text Lines
 @cindex lines
+@cindex logical lines, moving by
+@cindex physical lines, moving by
 
   Text lines are portions of the buffer delimited by newline characters,
 which are regarded as part of the previous line.  The first text line
@@ -515,6 +517,7 @@ Text Lines
 @node Screen Lines
 @subsection Motion by Screen Lines
 @cindex screen lines, moving by
+@cindex visual lines, moving by
 
   The line functions in the previous section count text lines, delimited
 only by newline characters.  By contrast, these functions count screen
diff --git a/lisp/simple.el b/lisp/simple.el
index a0f2da7152..010a7ae563 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -6638,15 +6638,15 @@ (defun move-end-of-line (arg)
 	    (setq done t)))))))
 
 (defun move-beginning-of-line (arg)
-  "Move point to beginning of current line as displayed.
-\(If there's an image in the line, this disregards newlines
-which are part of the text that the image rests on.)
+  "Move point to visible beginning of current logical line.
+This disregards any invisible newline characters.
 
 With argument ARG not nil or 1, move forward ARG - 1 lines first.
 If point reaches the beginning or end of buffer, it stops there.
 \(But if the buffer doesn't end in a newline, it stops at the
 beginning of the last line.)
-To ignore intangibility, bind `inhibit-point-motion-hooks' to t."
+To ignore intangibility, bind `inhibit-point-motion-hooks' to t.
+For motion by visual lines, see `beginning-of-visual-line'."
   (interactive "^p")
   (or arg (setq arg 1))
 
diff --git a/src/editfns.c b/src/editfns.c
index 9b76ae23ff..7e16fbd0ed 100644
--- a/src/editfns.c
+++ b/src/editfns.c
@@ -910,7 +910,8 @@ DEFUN ("line-beginning-position",
 
 This function ignores text display directionality; it returns the
 position of the first character in logical order, i.e. the smallest
-character position on the line.
+character position on the logical line.  See `vertical-motion' for
+movement by screen lines.
 
 This function constrains the returned position to the current field
 unless that position would be on a different line than the original,
-- 
2.11.0

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: Markus Triska <triska@metalevel.at>,  35899@debbugs.gnu.org
> Date: Fri, 21 Jun 2019 06:05:22 -0400
> 
> >>    (If there’s an image in the line, this disregards newlines
> >>    which are part of the text that the image rests on.)
> >> 
> >> Hence, I expect this to move to position 1. For comparison, when I press
> >> C-a, it does move to position 1, as expected.
> >
> > "the text that the image rests on" refers to the text which is
> > "covered" by the display property, not the newlines in the binary data
> > that constitutes the image file's data.
> 
> If I create an image which rests on some newlines like this:
> 
>     (let ((img (create-image "bug-35899-hello.png")))
>       (insert "abc")
>       (insert-image img "foo\nbar\nbaz")
>       (insert "def"))
> 
> Then with point after "def", move-beginning-of-line stops "inside" the
> image.  And I don't see anything in its code which would allow it to
> skip the image.  Isn't this just a doc bug?

Sorry, I don't understand the scenario, or cannot reproduce it.  For
starters, there's no bug-35899-hello.png, but I guess 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?

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

[Noam Postavsky]

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).  I guess the switch to minibuffer affects things somehow?

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"))

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.

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

[Noam Postavsky]

Eli Zaretskii <eliz@gnu.org> writes:
 
>> 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.

Ah right, I misinterpreted the behaviour.

>> 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.

Right, the proposed change just stops attempting to describe it at all
(and adds references to visual line movement, which solves the OP's
problem).

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

[Lars Ingebrigtsen]

Noam Postavsky <npostavs@gmail.com> writes:

>> 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.
>
> Right, the proposed change just stops attempting to describe it at all
> (and adds references to visual line movement, which solves the OP's
> problem).

It seems that everybody agreed on the doc fixes, but they weren't
applied at the time, so I did that now.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no