move-beginning-of-line

[Kim F. Storm]

As I indicated in another mail today, I have been looking at a problem
with moving to the beginning of a line in a window with the following
appearence:

abc
 [     ]
x[IMAGE]yz
 [     ]
def

Now, if I place the cursor on x, and do C-e, cursor moves to z.
If I then do C-a, cursor moves to y, not x.

The IMAGE is layed on top (via a display property) of text that ends
in a newline, so formally, C-a (beginning-of-line) DTRT.

However, from a user point of view, this is !TRT.


Contrary to what I previously thought, this is not caused by an error
in the move_it_vertically_backward function -- it is simply the way
bolp and beginning-of-line work, i.e. they don't care if the newline
before point is invisible.


To fix this, I propose adding the following command to simple.el and
binding it to C-a:


(defun move-beginning-of-line (arg)
  "Move point to beginning of current display line.
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.
To ignore intangibility, bind `inhibit-point-motion-hooks' to t.

This command does not move point across a field boundary unless doing so
would move beyond there to a different line; if ARG is nil or 1, and
point starts at a field boundary, point does not move.  To ignore field
boundaries bind `inhibit-field-text-motion' to t."
  (interactive "p")
  (or arg (setq arg 1))
  (if (/= arg 1)
      (line-move (1- arg) t))
  (let (done pos)
    (while (not done)
      (beginning-of-line 1)
      ;; (not bolp) means that it stopped at a field boundary.
      (if (or (bobp) (not (bolp)))
          (setq done t)
        (sit-for 0)
        (if (and (consp (setq pos (pos-visible-in-window-p (point) nil t)))
                 (= (car pos) 0))
            (setq done t)
          (backward-char 1))))))


I don't quite understand all of the "line-move" stuff in simple.el, so
since this function looks quite different from its move-end-of-line
counter-part, I would appreciate if someone would take a look at this
to see whether it breaks something.

Please also check if the doc string describes what's going on.

-- 
Kim F. Storm <address@hidden> http://www.cua.dk