Re: Something is rotten with end-of-line and move-end-of-line

[David Kastrup <dak@gnu.org>]

lorentey@elte.hu (Lőrentey Károly) writes:

> David Kastrup <dak@gnu.org> writes:
>>> There is a test case given in the discussion that demonstrates the
>>> original problem:
>>>
>>> 	(progn
>>> 	 (insert "\nab")
>>> 	 (insert-image-file "../etc/splash.xpm")
>>> 	 (move-end-of-line 1) 
>>> 	 (insert "def\n"))
>>>
>>> move-b/e-of-line move across the image to the line ending that
>>> corresponds to what is displayed on the screen, while the builtin
>>> b/e-of-line variants stop at the hidden newlines embedded in the image
>>> file.
>>
>> Correct me if I am wrong, but we move point away from invisible areas
>> anyway in the keyboard input loop, so there is no necessity to let
>> move-end-of-line do the deed explicitly in order to get
>> user-comprehensible behavior, right?
>
> Consider the above example, when point is after the inserted image:
>
> 	ab[IMAGE]def<!>
>
> Executing `beginning-of-line' stops right after the image, which is
> not what the user expects.
>
> 	ab[IMAGE]<!>def

Why would it do that?  beginning-of-line moved backwards, so I'd expect

ab<!>[IMAGE]def

> Similarly, from the other way around, `end-of-line' stops just
> before the image.  (Note that the text that is hidden behind the
> image has display and intangible properties only, it is not
> invisible.

Pretty much the same with regard to the keyboard loop.

> However, `end-of-line' and `beginning-of-line' behave the same
> (well, similar) way with invisible newlines.)

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum