From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stuart D. Herring" Newsgroups: gmane.emacs.devel Subject: RE: Graphical Kill node in Emacs manual Date: Tue, 22 Aug 2006 12:54:44 -0700 (PDT) Message-ID: <34833.128.165.123.18.1156276484.squirrel@webmail.lanl.gov> References: Reply-To: herring@lanl.gov NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1156276538 4567 80.91.229.2 (22 Aug 2006 19:55:38 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 22 Aug 2006 19:55:38 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 22 21:55:34 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GFcL3-0007P7-TI for ged-emacs-devel@m.gmane.org; Tue, 22 Aug 2006 21:55:06 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GFcL3-00013D-Eo for ged-emacs-devel@m.gmane.org; Tue, 22 Aug 2006 15:55:05 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GFcKq-00011W-Ai for emacs-devel@gnu.org; Tue, 22 Aug 2006 15:54:52 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GFcKp-0000yw-1B for emacs-devel@gnu.org; Tue, 22 Aug 2006 15:54:51 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GFcKo-0000yR-Qd for emacs-devel@gnu.org; Tue, 22 Aug 2006 15:54:50 -0400 Original-Received: from [192.65.95.54] (helo=mailwasher-b.lanl.gov) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GFcSU-0001Bb-5l for emacs-devel@gnu.org; Tue, 22 Aug 2006 16:02:46 -0400 Original-Received: from mailrelay2.lanl.gov (mailrelay2.lanl.gov [128.165.4.103]) by mailwasher-b.lanl.gov (8.13.6/8.13.6/(ccn-5)) with ESMTP id k7MJsjwS014467 for ; Tue, 22 Aug 2006 13:54:45 -0600 Original-Received: from webmail1.lanl.gov (webmail1.lanl.gov [128.165.4.106]) by mailrelay2.lanl.gov (8.13.6/8.13.6/(ccn-5)) with ESMTP id k7MJsibf013739; Tue, 22 Aug 2006 13:54:44 -0600 Original-Received: from webmail1.lanl.gov (localhost.localdomain [127.0.0.1]) by webmail1.lanl.gov (8.12.11.20060308/8.12.11) with ESMTP id k7MJsimg016462; Tue, 22 Aug 2006 13:54:44 -0600 Original-Received: (from apache@localhost) by webmail1.lanl.gov (8.12.11.20060308/8.12.11/Submit) id k7MJsiqu016460; Tue, 22 Aug 2006 12:54:44 -0700 X-Authentication-Warning: webmail1.lanl.gov: apache set sender to herring@lanl.gov using -f Original-Received: from 128.165.123.18 (SquirrelMail authenticated user 196434) by webmail.lanl.gov with HTTP; Tue, 22 Aug 2006 12:54:44 -0700 (PDT) In-Reply-To: Original-To: "Drew Adams" User-Agent: SquirrelMail/1.4.6-7.el3.7lanl X-Priority: 3 (Normal) Importance: Normal X-PMX-Version: 4.7.1.128075 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:58744 Archived-At: > 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. Davis -- 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 shipping.