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 16:30:48 -0700 Message-ID: <000b01c8ae3e$e269a980$0200a8c0@us.oracle.com> References: <002501c8ad70$af83c510$0200a8c0@us.oracle.com> <004201c8adc1$7caec120$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 1209943917 2480 80.91.229.12 (4 May 2008 23:31:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 4 May 2008 23:31:57 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Eli Zaretskii'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 05 01:32:33 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 1Jsngx-0000Fr-04 for ged-emacs-devel@m.gmane.org; Mon, 05 May 2008 01:32:27 +0200 Original-Received: from localhost ([127.0.0.1]:46345 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JsngF-0007sb-6X for ged-emacs-devel@m.gmane.org; Sun, 04 May 2008 19:31:43 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JsngB-0007qS-Dr for emacs-devel@gnu.org; Sun, 04 May 2008 19:31:39 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jsng9-0007n4-8Y for emacs-devel@gnu.org; Sun, 04 May 2008 19:31:39 -0400 Original-Received: from [199.232.76.173] (port=54963 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jsng9-0007mr-3W for emacs-devel@gnu.org; Sun, 04 May 2008 19:31:37 -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 1Jsnfv-0000uT-8K; Sun, 04 May 2008 19:31:23 -0400 Original-Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m44NVKOI018194; Sun, 4 May 2008 17:31:20 -0600 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m44NVJsv030089; Sun, 4 May 2008 17:31:19 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3665662471209943830; Sun, 04 May 2008 16:30:30 -0700 Original-Received: from dradamslap1 (/141.144.89.88) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 04 May 2008 16:30:30 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciuFO5CAD0XSSBORHerMr5lfdM0aAAGdMNQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-reply-to: 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:96462 Archived-At: > > And if `x-selection-exists-p' is not the way to test for a given > > selection (e.g. SECONDARY) on Windows, then what is? > > What does it mean ``to test for a given selection'' on Windows? > Please explain this in Windows terms, since there're no selections on > Windows. Secondary. Whether you call it something different for Windows or not (excuse my ignorance of the official terminology), such a selection (or whatever it is) exists in Emacs. It is called "secondary selection" in the doc. It is shown with face `secondary-selection'. Please let me know the correct lingo for this thingy, but I think you know by now what I'm referring to. Pas de mauvaise foi STP. > > 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? > > Probably not, maybe, and yes. Great, thank you. See, you knew what I meant by "secondary selection" after all. > > > 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? ;-) > > It misbehaves when it behaves against your expectations as a Windows > user who knows that there's only one system-wide buffer called > ``clipboard''. There may be only one system-wide buffer called "clipboard", but I am interested (as a Windows user) in both the secondary selection and the first one (X primary, Emacs region, clipboard, whatever - I will accept and use all such selected portions of text). > > (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")) > > > > However, on Windows, w32-win.el calls > > `menu-bar-enable-clipboard' (at top-level, > > Yes, because that's what Windows users expect. They expect the result, not the implementation. They don't care how it's implemented. It is not standard practice to do such things at top-level nowadays, but there could be special reasons why it is done here (what are they?). More typically, such code is wrapped in a minor mode or other command or a user option, so that simply loading the library doesn't change the user's environment. Yes, I see that w32-win.el is intentionally an exception in this regard, but I wonder if this part needs to be that way, whether that is TRT. > > 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. > > Sorry, I don't understand what is it that you think is wrong with this > code. I'm not saying it's definitely right, I just don't understand > what is your criticism. Question, not criticism. I'm asking why it is the way it is. What I wrote next should have made what I meant by that clear: It's hard for a user to extend the approach used, to include a Paste Secondary menu item (for example). Call it criticism if you like. I'm just looking for a good way to do that. > > 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. > > You lost me, sorry. Are we still talking about Windows? Because > there isn't (and cannot be) a Paste Secondary menu item there. Dunno how to make it clearer. Yes, I'm still talking about Windows. I want to add a Paste Secondary item. On Windows. I don't care if you don't want to call it a "secondary selection", but you know perfectly well what I mean. It exists on Windows too, and I want to add a menu item to yank it. The approach taken with `menu-bar-enable-clipboard' and the double versions of copy, cut, and paste commands in menu-bar.el does not help in this endeavor - that approach gets in the way. Did you look at the code I sent that uses variable `x-select-enable-clipboard'? That way of doing things seems cleaner and more flexible to me. Code or users can set that variable to affect all commands that use it, at once. With the `menu-bar-enable-clipboard' approach, on the other hand, one would need to jump through hoops to add a Paste Secondary item, because `menu-bar-enable-clipboard' has as its mission to control all such functions, and it didn't happen to foresee that one. My impression from your last reply is that the implementation on Windows of `x-selection-exists-p' is indeed incorrect for `SECONDARY' - it returns nil when a secondary selection exists, as I said at the beginning, whereas (x-get-selection 'SECONDARY) correctly returns the secondary selection text (not nil). I think that this is a bug. You almost had me convinced that this was not a bug and `x-selection-exists-p' and `x-get-selection' are irrelevant for Windows, but my impression now is that you either did not follow me or you are mistaken. The following code, which I use for pasting the secondary selection by menu, has an :enable condition that works, but it uses `x-get-selection', not `x-selection-exists-p' for the existence test. If `x-selection-exists-p' gets fixed, then I'll use that instead, but until then, I don't know another way to implement the :enable test so that it works. (define-key menu-bar-edit-menu [yank-secondary] '(menu-item "Paste Secondary" yank-secondary :help "Paste secondary selection." :enable (and (fboundp 'x-get-selection) ;; `x-selection-exists-p' does not ;; work here, so use `x-get-selection'. (x-get-selection 'SECONDARY) (not buffer-read-only))))