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


Hal Huntley complains that there is a bug causing recently killed
things disappear from the kill ring.

    Date: Mon 30 Mar 87 10:03:01-PST
    From: Hal Huntley <HAL@SRI-NIC.ARPA>
    Subject: kill bug
    To: bug-emacs@SRI-NIC.ARPA
    cc: hal@SRI-NIC.ARPA
    Message-ID: <12290556452.29.HAL@SRI-NIC.ARPA>

    I did the following sequence:

    Move to a line and get two words from the end of the line...
    Kill to end of line (C-K). 		; kill 1
    Add some text.
    Go to next line (C-N).
    Back up two words (M-B twice).
    Kill to end of line (C-K).  		; kill 2
    Do C-Y, M-Y to get back the line I killed just above.
    Next line.
    Back 2 words.
    Kill to end of line.  			; kill 3
    C-Y, M-Y.

    Voila! The previous kill (kill 2) to end of line is NOT there to yank
    back!!!!  Not only that, but repeated M-Y's shows me that the second

    I just reproduced this and got the same results even if I did not add
    text after the first kill. Is it our NIC implementation only?  I would
    imagine so..

    This needs to be fixed!

    I have reproduced this now several times.  I will be happy to
    show anyone what I've done... (but knowing my luck when I show the
    Doctor, the symptoms will go away.....)


I'm not saying that this behavior is particularly useful , but it is
consistent with the vector model of the kill ring.  Interested parties can
use M-X View Q-Registerâ—Š..K to see the kill ring and check on my

Here's how the kill vector works:
   When you do C-Y, the text in kill buffer position 0 gets inserted into
   the buffer.

   When you do M-Y, that text gets deleted; the copy of the
   text that was in slot 0 gets moved to slot 8, and everything else
   moves down one, resulting in the previously-killed text moving from
   slot 1 to slot 0; then EMACS inserts the new slot 0 text.

   When you do C-K, the deleted text goes from the buffer to slot zero,
   and bumps everything else up by one slot.  The thing which was in slot
   8 is lost.

In Huntley's example, the thing in slot 8 which gets lost is the very
thing which was in slot 0 just before the M-Y.  Thus, C-Y M-Y C-K causes
the thing you C-Y'd to disappear forever.

GNU Emacs avoids this problem by keeping the kill ring in a list.  If the
list length is less than the maximum kill ring length, then moving the
item to the end of the list doesn't make it a candidate for expunging on
the next kill.

TECO Emacs could emulate this behavior by skipping all Q-vector elements
containing 0 in the rotate operation, and treating the vector as if it
ended at the last non-zero element.