[gnu.emacs.bug] gnu-emacs bug

Olin.Shivers@CENTRO.SOAR.CS.CMU.EDU (12/01/88)

There is a problem with the interaction between yank/yank-pop and
process output.

Yank and yank-pop delimit yanked text with the mark on the left and
the point on the right (in the normal case). Now, when you do a
subsequent yank-pop, yank-pop only executes if the previous command
was a yank or yank-pop, so it knows for sure that the previously yanked
text, which needs to be deleted, is tightly delimited by point and
mark -- the user hasn't had a chance to mess around. So it blithely
deletes from mark to point, secure that it is guaranteed to only
delete the text inserted by the previous yank/yank-pop.

Alas, this is not the case. If you yank text when point is at the
process mark, then the mark, delimiting the yanked text on the left,
is placed at the process mark. *If the process subsequently outputs
text before the next yank-pop* then that text sneaks in to the right
of the mark. And so it will be deleted by the subsequent yank-pop.

So yank-pop can sometimes delete text that was not yanked. This is
not good. 

The way to win in gnu emacs is to arrange for process output to insert text
using INSERT-BEFORE-MARKERS.

You might think that using INSERT-BEFORE-MARKERS instead of INSERT
merely exchanges this bug for its mirror-image cousin, wherein text
can sneak in on the right. This is not the case, but realising that takes
a little careful case analysis. If you can't see this, let me know, and I
will write it out for you. 

(Actually, there is one symmetric bug you can get with INSERT-BEFORE-MARKERS:
if there was a yank-pop-like command in gnumacs that assumed the previously
typed command had inserted text to be deleted with INSERT-BEFORE-MARKERS,
delimiting it on the left with point and on the right with mark, then doing
process output with INSERT-BEFORE-MARKERS could screw that command.
Fortunately, this is a very odd thing to do; it doesn't happen anywhere* in
the gnumacs lisp sources I have on hand (18.49). Since yank/yank-pop use
INSERT, doing process output with INSERT-BEFORE-MARKERS will fix the
interaction with yank/yank-pop -- a very important existing command -- at the
cost of introducing a potentially buggy interaction for commands that do not
currently exist, and are not likely to be written. The general solution is
provided by the sticky-left and sticky-right markers that Hemlock has -- you
can use them as matched pairs to bracket delimited text. This is not available
in gnumacs. So it goes.)

Note that this interaction doesn't just screw yank/yank-pop, but also
the input-history commands in the process-in-a-window modes.

I spoke to RMS about this in August, but he has probably forgotten.
He agreed that this was a bug.
	-Olin

* INSERT-BEFORE-MARKER is used only seven times, in ftp.el, subr.el, and
  xscheme.el. INSERT-BEFORE-MARKER is used in xscheme.el in a process
  sentinel, I believe, to work around the yank interaction bug. I do not
  understand why INSERT-BEFORE-MARKER is used instead of INSERT in ftp.el
  and subr.el. Neither ftp.el or subr.el's MOMENTARY-STRING-DISPLAY use
  any markers!