From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Graphical Kill node in Emacs manual Date: Tue, 22 Aug 2006 13:28:36 -0700 Message-ID: References: <34833.128.165.123.18.1156276484.squirrel@webmail.lanl.gov> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1156278547 11697 80.91.229.2 (22 Aug 2006 20:29:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 22 Aug 2006 20:29:07 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 22 22:29:01 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 1GFcrs-0005K7-Pp for ged-emacs-devel@m.gmane.org; Tue, 22 Aug 2006 22:29:01 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GFcrs-0000Sx-3l for ged-emacs-devel@m.gmane.org; Tue, 22 Aug 2006 16:29:00 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GFcrg-0000Ss-D9 for emacs-devel@gnu.org; Tue, 22 Aug 2006 16:28:48 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GFcrc-0000Sd-JI for emacs-devel@gnu.org; Tue, 22 Aug 2006 16:28:47 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GFcrc-0000Sa-Gv for emacs-devel@gnu.org; Tue, 22 Aug 2006 16:28:44 -0400 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1GFczI-0004hI-Kj for emacs-devel@gnu.org; Tue, 22 Aug 2006 16:36:40 -0400 Original-Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k7MKSfa5012046; Tue, 22 Aug 2006 15:28:41 -0500 Original-Received: from dradamslap (dhcp-amer-csvpn-gw2-141-144-72-180.vpn.oracle.com [141.144.72.180]) by rgmgw2.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k7MKSe94023074; Tue, 22 Aug 2006 14:28:40 -0600 Original-To: , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: <34833.128.165.123.18.1156276484.squirrel@webmail.lanl.gov> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE 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:58746 Archived-At: This is very helpful. Thanks. I'm not sure what this should mean for the Emacs doc, if anything. Regarding the term "clipboard", here is another data point: Its meaning as a buffer or other storage area (essentially, a variable - the "reuse area" you mention), or as a set of these, predates MS Windows. It has been used that way in applications such as Framemaker, for instance, since long before MS Windows was born. Though the kill ring has additional properties, it seems very close to the notion of clipboard in both MS Windows and in applications such as Framemaker (on whatever platform). It sounds, IIUC, as if it is the X Window use of the term that is the most exceptional (and most complex). When Emacs interfaces with X-Window, this also complicates the explanation of the Emac kill ring, but otherwise, I'd think that the explanation of the kill ring would be straightforward. Do I understand this correctly? In most uses of the term "clipboard", it is simply a memory location (or set of such), but in X Window, it is a dynamic request to an app, which can return anything it wants. (And, there are other such selections: primary, secondary...) If this is the case, why not write the Emacs doc to refer to the term "clipboard" in the widely understood sense, except when specifically speaking about X Window (and point out this shift in terminology)? I think it would help users, who are used to this simple notion of clipboard, to mention that the kill ring is like a clipboard. Do you, Davis, who seem to understand this well, think the doc could be made clearer in this area? If so, could you suggest something? Thanks again for the info. - Drew > 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