Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!dsg.csc.ti.COM!Kimbrough
From: Kimbrough@dsg.csc.ti.COM (Kerry Kimbrough)
Newsgroups: comp.windows.x
Subject: Cut-and-paste
Message-ID: <2796138891-8202615@Sierra>
Date: 9 Aug 88 17:14:51 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 23


   > So I say 'Cut cut buffers out of X -- and the rest'. Who would argue?

I'll pick up the gauntlet.  Actually, I agree with you -- the semantics of
cut'n'paste is a client function.  In fact, it's not really accurate to say that
cut buffers are "in" X.  The most you can say along this line is that the X
protocol predefines the atoms PRIMARY, SECONDARY, CUT_BUFFER_0, ...
CUT_BUFFER_7.  However, the meaning and use of these atoms are left completely
undefined.

Certainly, cut'n'paste, as it is commonly known, is a user-initiated operation.
That is, it must have *some* user interface.  Specifically, the clients
participanting in the operation (the cuttee and the pastee) are addressed by the
user via their user interfaces: "Cut from here and paste to there".  Since the
participant clients are sharing an X server and since X provides a client
channel that is independent of the communications hw/sw layers, it's eminently
practical to use the server as the intermediary in cut'n'paste.  That is, cuttee
sends a message to the server to store the cut info, pastee sends a message to
the server to retrieve the cut info.  That is how the PRIMARY, SECONDARY,
CUT_BUFFER_0, ...  CUT_BUFFER_7 property atoms are intended to be used (although
even this is merely a well-known inter-client convention and not a "feature" of
X).  But clients are responsible for defining the user gesture to perform the
cut/paste, for figuring out exactly what info is to be cut, and for figuring out
exactly what is to be done with the cut info when it is retrieved.