[Top][All Lists]

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

RE: Graphical Kill node in Emacs manual

From: Stuart D. Herring
Subject: RE: Graphical Kill node in Emacs manual
Date: Tue, 22 Aug 2006 12:54:44 -0700 (PDT)
User-agent: SquirrelMail/1.4.6-7.el3.7lanl

> Perhaps I misspoke - I'm unclear on when the X clipboard is used to
> copy+paste between applications (the subject of this node) and when it is
> not used.
> [...]
> Yes, if the Clipboard section helps understand the stuff on inter-app
> yanking, then an xref would help. As I say, I myself am not clear when the
> Emacs (X) clipboard is actually used. I can copy and paste between apps,
> but
> I have no idea if I'm using the X clipboard (I'm using MS Windows).

Just so everyone is up-to-date:
Any application can obviously store user data and provide it for reuse. 
Call this the "reuse area".  Emacs calls it the kill ring.  Windowing
environments often provide a common communication mechanism for text (and
sometimes other objects) to be transferred between windows (and even
between processes).

On Windows, this is implemented with a memory buffer, called the Windows
clipboard (or just "the clipboard").  Any application can write or read
this as it wishes; typically the writing is associated with "Cut" (Emacs:
kill) or "Copy" actions, and the reading with "Paste" actions (called
yanking in Emacs).

On X, this concept is implemented somewhat differently.  There are a set
of tokens, called "selections" -- two of which are labelled "primary" and
"clipboard" -- that a process may possess.  Note that these are not
buffers and do not hold data.  Instead, when a process decides that the
user has copied something, it simply requests the token.  When another
process wants to use the copied data, it asks the X server for the text
associated with the token, and the X server in turn asks the owning
process.  That process can reply with whatever data it wants -- typically
"what the user copied", but it can even vary from request to request
without user action if the process chooses -- and that data is passed by X
to the requester.  Note that this has the unfortunate side effect that
when a process dies, its "clipboard data", if any, is lost.

Further confusion on X: there are also buffers (like Windows has) called
"cut buffers".  However, these are deprecated (or at least nearly so)
because they are inflexible, may have size limitations, and require data
communication between a client and the server whenever something is
copied, whether or not it is ever used.   (Remember that in X the client
and server may easily be on different continents.)

Yet more X confusion: on Mac under X, there is the Aqua clipboard (which
as far as I know is much like the Windows one) and then the complete set
of X mechanisms; the issue of synchronization between these two
environments is separate and typically outside of Emacs' control.

Finally, there is the question of whether and how processes synchronize
their reuse areas with the system buffers or tokens.  On Windows, this is
often a non-issue -- the only standard mechanism is a buffer, and the
process can write to it and forget that it even did so.  On X, it varies
between programs because (A) there are multiple tokens and buffers and (B)
using selections implies that the process must remember the text for an
indeterminate length of time -- possibly even after the text is no longer
otherwise "active" in the application.  For instance, a user copies some
text in a terminal program, but then executes a verbose command therein
which scrolls the copied text out of the scrollback.  Some programs will
forget the text (and hopefully inform the X server that they no longer
have anything to provide), while others will make a separate copy of the
text then or at the time of the copy command and keep it around until
something else is copied (whether in that application or another).

Emacs has its own complications because it wants its reuse area to be more
powerful than either of these standard clipboard mechanisms.  Emacs'
policy is to, after every kill, copy it to the Windows clipboard or store
it to an X cut buffer (if it's small) and advertise it as one or both of
the "primary" and "clipboard" X selections.  When text is to be yanked,
Emacs consults the Windows clipboard and/or the various X resources and
uses text from them if it's not text that Emacs itself put there.  If it
does so, that text is copied onto the kill ring as well as yanked. 
Otherwise, the kill ring (and the current position within it) is used as
usual.  There are a few options in term/x-win.el and w32-fns.el that
control some of the specifics of this, and the whole operation can be
disabled or rewritten via the `interprogram-cut-function' and
`interprogram-paste-function' variables.

I hope this helps people understand the scenarios involved with killing
and yanking a bit better.  As a final note, a couple of problems that have
been observed in this area:
1. Keyboard macros that use the kill ring will also end up using the
system transfer mechanisms.  This can be a bad thing if the user was
hoping to use them while letting a macro run "in the background".
2. Emacs' rules for picking good X selections to use and its management of
its own selections weren't perfect the last time I checked, but it's hard
to come up with an optimum set.  There may yet be real bugs, though.


This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during

reply via email to

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