move-beginning-of-line

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 <storm@cua.dk> http://www.cua.dk

Re: move-beginning-of-line

[Luc Teirlinck]

Kim Storm wrote:

   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.

Sorry for replying so late to this, but is there some extremely good
(that is, absolutely unavoidable) reason why that image is layed on
top of text that _ends in a newline_ (or just contains newlines)?  Is
that fact, rather than beginning-of-line not the problem?  Trying to
"fix" the C-a behavior you consider "wrong" using
`move-beginning-of-line' is not going to change the fact that every
other Emacs command or function will still consider the offending
newline to be the end of a line _and_ to be visible (unless it has the
invisibility property).  Giving newlines a display property is a very
dubious thing to do.  I do not believe that very much in Emacs is
prepared for newlines with a display property.

   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.

And on top of that, unless that newline has the invisibility property,
Emacs considers it to be visible, whether the user can see it or not.

Sincerely,

Luc.

Re: move-beginning-of-line

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Kim Storm wrote:
>
>    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.
>
> Sorry for replying so late to this, but is there some extremely good
> (that is, absolutely unavoidable) reason why that image is layed on
> top of text that _ends in a newline_ (or just contains newlines)?  Is
> that fact, rather than beginning-of-line not the problem?  

For example, this is how insert-image-file works.
Try to eval this in an empty buffer:

(progn
 (insert "\nab")
 (insert-image-file "../etc/splash.xpm")
 (move-end-of-line 1) 
 (insert "def\n"))


This could be considered a bug in insert-image-file.

I wonder how preview-latex handles this, as it uses images over
multiline text _a lot_ ...?   Does beginning-of-line work ok
with images in the middle of lines?  If so, how?


>                                                            Trying to
> "fix" the C-a behavior you consider "wrong" using
> `move-beginning-of-line' is not going to change the fact that every
> other Emacs command or function will still consider the offending
> newline to be the end of a line _and_ to be visible (unless it has the
> invisibility property).  Giving newlines a display property is a very
> dubious thing to do.  I do not believe that very much in Emacs is
> prepared for newlines with a display property.

True.  

This _is_ a problem, but it is not new.


>
>    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.
>
> And on top of that, unless that newline has the invisibility property,
> Emacs considers it to be visible, whether the user can see it or not.

True.  I have tried to put invisibile property on the image text, but
it doesn't give good result for me ... anybody want to experiment
with that, to find something which works ?

If we can fix the places where a display property gives problems, I
guess we could get rid of move-beginning-of-line (or at least not
have it as the default binding for C-a).

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

Re: move-beginning-of-line

[Ralf Angeli]

* Kim F. Storm (2005-03-14) writes:

> I wonder how preview-latex handles this, as it uses images over
> multiline text _a lot_ ...?

A typical example would be LaTeX code like

Foo\footnote{Bar
baz} blah

which, with the help of preview-latex (or AUCTeX's folding
functionality), will get displayed as

Foo¹ blah

> Does beginning-of-line work ok
> with images in the middle of lines?  If so, how?

That depends.  With point at the end of the line in the example
`C-a' will move to the beginning of the line.  With
`beginning-of-line' point will end up inside of the overlay.

One can test this quite easily (circumventing preview-latex's
provisions for playing with point) with code like

(progn
  (insert "\nwww xxx\nyyy zzz")
  (overlay-put (make-overlay (- (point) 11) (- (point) 4)) 'display "111"))

If found it a bit peculiar that `M-x beginning-of-line RET' and `M-:
(beginning-of-line) RET' yielded different results.  In the former
case point will end up on the first "1" and in the latter case after
the last "1".

-- 
Ralf

Re: move-beginning-of-line

[David Kastrup]

Ralf Angeli <angeli@iwi.uni-sb.de> writes:

> * Kim F. Storm (2005-03-14) writes:
>
>> I wonder how preview-latex handles this, as it uses images over
>> multiline text _a lot_ ...?
>
> A typical example would be LaTeX code like
>
> Foo\footnote{Bar
> baz} blah
>
> which, with the help of preview-latex (or AUCTeX's folding
> functionality), will get displayed as
>
> Foo¹ blah
>
>> Does beginning-of-line work ok
>> with images in the middle of lines?  If so, how?
>
> That depends.  With point at the end of the line in the example
> `C-a' will move to the beginning of the line.  With
> `beginning-of-line' point will end up inside of the overlay.
>
> One can test this quite easily (circumventing preview-latex's
> provisions for playing with point)

But preview-latex's provisions for playing with point are actually
what is interesting to the user.

preview-latex uses post-command-hook to move point out of images after
each command.  It also uses pre-command-hook to remember point before
each command.  If the command moved backwards when ending up inside of
the image, preview-latex will move it to the start of the image,
otherwise to the end of the image.  As a result, pressing C-a to the
right of a multi-line image should move point to the front of the
image.  Similar with pressing C-e to the left of such an image.

> with code like
>
> (progn
>   (insert "\nwww xxx\nyyy zzz")
>   (overlay-put (make-overlay (- (point) 11) (- (point) 4)) 'display "111"))
>
> If found it a bit peculiar that `M-x beginning-of-line RET' and `M-:
> (beginning-of-line) RET' yielded different results.  In the former
> case point will end up on the first "1" and in the latter case after
> the last "1".

Hm, no idea about that one.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: move-beginning-of-line

[Ralf Angeli]

* David Kastrup (2005-03-14) writes:

> preview-latex uses post-command-hook to move point out of images after
> each command.  It also uses pre-command-hook to remember point before
> each command.  If the command moved backwards when ending up inside of
> the image, preview-latex will move it to the start of the image,
> otherwise to the end of the image.  As a result, pressing C-a to the
> right of a multi-line image should move point to the front of the
> image.  Similar with pressing C-e to the left of such an image.

With a five-day-old CVS Emacs `C-a' will move point to the start of
the _preceding_ line.  One can check this without preview-latex by
executing

(progn
  (insert "\nfoo\nbar")
  (overlay-put (make-overlay (- (point) 7) (point))
	       'display (create-image "splash.xpm" 'xpm)))

and typing `C-a' after that.

-- 
Ralf

Re: move-beginning-of-line

[Stefan Monnier]

> If found it a bit peculiar that `M-x beginning-of-line RET' and `M-:
> (beginning-of-line) RET' yielded different results.  In the former
> case point will end up on the first "1" and in the latter case after
> the last "1".

The place where point ends up when moving into an invisible (or "display"ed
or composed) area of text is not really well defined, because it tries to
DTRT based on how you got there, while at the same time trying to make sure
it never majorly screws up.

In the M-: and M-x cases, doing the right thing is not nearly as obvious as
you'd think because the "command" that does the work is actually the RET
which exits from the minibuffer and then runs the actual code, so the
"start point" and "end point" of the command are not even in the same
buffer, so inferring the direction of the movement is not done correctly.


        Stefan

Re: move-beginning-of-line

[Richard Stallman]

    In the M-: and M-x cases, doing the right thing is not nearly as obvious as
    you'd think because the "command" that does the work is actually the RET
    which exits from the minibuffer and then runs the actual code, so the
    "start point" and "end point" of the command are not even in the same
    buffer, so inferring the direction of the movement is not done correctly.

Maybe this can be improved if entering the minibuffer saves the "old
position" information and exiting it restores that information.  Want
to try that?

Re: move-beginning-of-line

[Richard Stallman]

    > Sorry for replying so late to this, but is there some extremely good
    > (that is, absolutely unavoidable) reason why that image is layed on
    > top of text that _ends in a newline_ (or just contains newlines)?

The general idea of of auto-image-file-mode, and of my new replacement
image-mode, is that the image sits on top of the text of the file.
This is so if you write the buffer to some other file, it will get the
right contents.  As long as we keep that idea, there will be newlines
in the file.

However, insert-image-file doesn't necessarily have to work this way.
It could instead make the image sit on top of a space, like
insert-image.

Does anyone see a reason why not to do this?

Re: move-beginning-of-line

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> Luc Teirlinck <teirllm@dms.auburn.edu> writes:
>
>> Kim Storm wrote:
>>
>>    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.
>>
>> Sorry for replying so late to this, but is there some extremely
>> good (that is, absolutely unavoidable) reason why that image is
>> layed on top of text that _ends in a newline_ (or just contains
>> newlines)?  Is that fact, rather than beginning-of-line not the
>> problem?

Where the overlay is used to give a different appearance to buffer
parts (where the text of those buffer parts is under user control), it
is not possible to avoid.

> For example, this is how insert-image-file works.
> Try to eval this in an empty buffer:
>
> (progn
>  (insert "\nab")
>  (insert-image-file "../etc/splash.xpm")
>  (move-end-of-line 1) 
>  (insert "def\n"))
>
>
> This could be considered a bug in insert-image-file.
>
> I wonder how preview-latex handles this, as it uses images over
> multiline text _a lot_ ...?  Does beginning-of-line work ok with
> images in the middle of lines?  If so, how?

As I said, preview-latex moves point out of images, so the cursor will
usually end up at the start of the image.  The effect is probably not
annoying enough as to cause people to complain.  preview-latex really
puts only a thin veil over the covered entities: if you move with
<left> or <right> into a preview, it unfolds again, and the same if
you search for text or do a query-replace.

So when editing, people understand that they are not dealing with the
equivalent of characters.  It is only when they are looking at the
screen that they want the illusion.

For example, we have had to stop AUCTeX from formatting stuff like

This is a very long line and continues for a while and then we have $E
  = mc^2$ and then the line continues for another while.

since preview-latex would make a single visual line like

This is a very long line and continues for a while and then we have [E=mc²] and then the line continues for another while.

out of it.  So we tricked AUCTeX into using formatting rules that
would "coincidentally" keep newlines out of inner structures as long
as they could be avoided.  And if they could not be avoided, it would
break just behind them, at least optionally.

>> Trying to "fix" the C-a behavior you consider "wrong" using
>> `move-beginning-of-line' is not going to change the fact that every
>> other Emacs command or function will still consider the offending
>> newline to be the end of a line _and_ to be visible (unless it has
>> the invisibility property).  Giving newlines a display property is
>> a very dubious thing to do.  I do not believe that very much in
>> Emacs is prepared for newlines with a display property.
>
> True.

False.  When Emacs 21.1 was coming up, I was plastering Gerd with bug
reports.  All sorts of cute little display errors, in particular
involving newlines.  Emacs took _quite_ a bit of beating in that area.
Now that was catering for inconsistent displays: cursor movement and
similar are not necessarily involved.  I'd be interested in seeing
stuff like auto-fill work sensibly in the presence of display
properties.  The best behavior for stuff like preview-latex would
probably result if filling kept track of both the visual line size as
well as the real buffer line size and caused a break when either was
exceeded.  Something like that.  But I guess this would not be a
sensible filling default in the general case of text properties, just
a nice option to have for preview-latex.  The sensible default would
probably just cater for what is visible, meaning that it would skip
across any display properties (filling changes inside of them don't
change the appearance).

> True.  I have tried to put invisibile property on the image text,
> but it doesn't give good result for me ... anybody want to
> experiment with that, to find something which works ?
>
> If we can fix the places where a display property gives problems, I
> guess we could get rid of move-beginning-of-line (or at least not
> have it as the default binding for C-a).

I am somewhat skeptical that this can be fixes in general...

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: move-beginning-of-line

[Kim F. Storm]

Istvan Marko <mi-emacs@kismala.com> writes:

> The version in the current CVS causes C-a to go to the beginning of
> the *screen* line instead of the beginning of the buffer line.


Thanks for noticing this.  I have installed a fix.

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