Re: move-beginning-of-line

[David Kastrup]

address@hidden (Kim F. Storm) writes:

> Luc Teirlinck <address@hidden> 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