[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Kastrup
Subject: Re: Something is rotten with end-of-line and move-end-of-line
Date: Tue, 29 Nov 2005 00:10:08 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

address@hidden (Lőrentey Károly) writes:

> David Kastrup <address@hidden> 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


> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]