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: x-selection-exists-p vs x-get-selection Date: Sun, 4 May 2008 01:33:10 -0700 Message-ID: <004201c8adc1$7caec120$0200a8c0@us.oracle.com> References: <002501c8ad70$af83c510$0200a8c0@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1209890080 21230 80.91.229.12 (4 May 2008 08:34:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 4 May 2008 08:34:40 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Eli Zaretskii'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 04 10:35:15 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JsZge-0006yB-5I for ged-emacs-devel@m.gmane.org; Sun, 04 May 2008 10:35:12 +0200 Original-Received: from localhost ([127.0.0.1]:46708 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JsZfw-0002cw-9i for ged-emacs-devel@m.gmane.org; Sun, 04 May 2008 04:34:28 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JsZfq-0002cQ-Tx for emacs-devel@gnu.org; Sun, 04 May 2008 04:34:22 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JsZfq-0002c2-9F for emacs-devel@gnu.org; Sun, 04 May 2008 04:34:22 -0400 Original-Received: from [199.232.76.173] (port=48150 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JsZfp-0002bt-Ti for emacs-devel@gnu.org; Sun, 04 May 2008 04:34:21 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JsZfd-0000YB-SE; Sun, 04 May 2008 04:34:10 -0400 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m448Xxpe018271; Sun, 4 May 2008 02:34:00 -0600 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m445U1n3014180; Sun, 4 May 2008 02:33:59 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3663971711209889977; Sun, 04 May 2008 01:32:57 -0700 Original-Received: from dradamslap1 (/141.144.81.43) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 04 May 2008 01:32:57 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcitnS3N4VpXuD21RSuqyoScidCWdwAFhMEw X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 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:96425 Archived-At: > > I don't understand `x-selection-exists-p'. I select some > > text with meta mouse clicks or drags, to create a secondary > > selection. (x-get-selection 'SECONDARY) > > returns that secondary-selection text, as I would expect. > > > > But (x-selection-exists-p 'SECONDARY) returns nil - I > > expected t. The doc string says: "Whether there is an owner > > for the given X Selection." I am on Windows, > > with `x-select-enable-clipboard' = t, if that is important. > > > > Is there a bug here? If not can someone please enlighten me? > > > > How should I understand `x-selection-exists-p'? It is used, > > for instance, in menu-bar.el, to determine whether to enable > > some selection menus, such as Paste. > > These functions make sense only on X window systems. I see. But they are used on all platforms. I see `x-selection-exists-p' used in menu-bar.el as an :enable check, for instance, as I mentioned. And if `x-selection-exists-p' is not the way to test for a given selection (e.g. SECONDARY) on Windows, then what is? > Their functionality on Windows is tuned to make their callers DTRT, but > that's all; there's no underlying theory that would make sense on > Windows besides that. There are no ``selections'' on Windows, and no > ``owners'' of selections. If you want to understand these functions' > semantics on X, read some X manual. BTW, the Emacs documentation calls it "secondary selection", even if "there are no ``selections'' on Windows". The entire section in the Emacs manual about Secondary Selection is written as if it is only for the X Window System, but the same or similar behavior exists for Emacs on Windows. Is it TRT that the doc is written this way? Shouldn't there be, at a minimum, a sentence saying that this works for other than just X-Window Emacs? Is this just a case of Emacs showing its legacy? > If you have specific situations where the code using them misbehaves > on Windows, please describe those situations. How to know if it "misbehaves" on Windows, since you've said that there is no prescribed behavior for Windows? ;-) They are meaningless on Windows. Nevertheless, they are used. Actually, what appears to happen is this - this is the code for the standard Paste menu item: (define-key menu-bar-edit-menu [paste] '(menu-item "Paste" yank :enable (and ;; Emacs compiled --without-x doesn't have ;; x-selection-exists-p. (fboundp 'x-selection-exists-p) (x-selection-exists-p) (not buffer-read-only)) :help "Paste (yank) text most recently cut/copied")) [BTW, in spite of the comment (unless I'm misunderstanding it), (fboundp 'x-selection-exists-p) returns t on Windows.] However, on Windows, w32-win.el calls `menu-bar-enable-clipboard' (at top-level, when it is loaded - not as a minor mode or something), which substitutes `clipboard-yank' for `yank' as [paste]. And that uses this enablement instead: (put 'clipboard-yank 'menu-enable '(and (or (and (fboundp 'x-selection-exists-p) (x-selection-exists-p)) (x-selection-exists-p 'CLIPBOARD)) (not buffer-read-only))) That seems a roundabout and fragile way to do things. It's fragile because it means that function `menu-bar-enable-clipboard' must deal explicitly with every command that might ever need to be treated this way. If a user wants to add a Paste Secondary menu item, then s?he must add a `clipboard-yank-secondary' command and also do, for that function, what `menu-bar-enable-clipboard' does for the others, on all (and on only) the right platforms. That seems like an ugly hack. I'm not sure what a better approach would be, but what about just using a global variable for such enablement, instead of calling `menu-bar-enable-clipboard'? The `clipboard-*' functions themselves use `x-select-enable-clipboard'. Couldn't that be used directly in the :enable clause, and then just have a single set of commands? IOW, just use `yank', instead of `clipboard-yank', but with an :enable value that uses `x-select-enable-clipboard': (define-key menu-bar-edit-menu [paste] '(menu-item "Paste" yank :enable (and (or (and (fboundp 'x-selection-exists-p) (x-selection-exists-p)) (and x-select-enable-clipboard (x-selection-exists-p 'CLIPBOARD))) (not buffer-read-only)) :help "Paste (yank) text most recently cut/copied")) (Or perhaps the third `and' should come before the second?) That way, too, users or code could turn such menu items on and off using the variable, whereas now they can only turn them on (not off), using function `menu-bar-enable-clipboard'. Dunno if that would be useful, but it is less clunky. I imagine there is a good reason for doing things the way they are done, but it's not clear to me. Perhaps it has something to do with this comment about pure space in `menu-bar-enable-clipboard'? ;; We can't use constant list structure here because it becomes pure, ;; and because it gets modified with cache data. I'm ignorant about the pure space and cache data treatment. Could you explain this, if it is in fact what is behind the complicated way things are done for these menu items? If it is not the reason, then what is? I'm not so much arguing that the code should be different as I am trying to understand why it is the way it is. If the code stays the way it is, then how should a user add a Paste Secondary item with proper enablement? One workaround, at least for Windows, would be to just use (x-get-selection 'SECONDARY) instead of (x-selection-exists-p 'SECONDARY) - that seems to work, for whatever reason - it returns non-nil on Windows only when there is a secondary. That might not be kosher, but what's the alternative?