From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: x-selection-exists-p vs x-get-selection Date: Sun, 04 May 2008 21:29:50 +0300 Message-ID: References: <002501c8ad70$af83c510$0200a8c0@us.oracle.com> <004201c8adc1$7caec120$0200a8c0@us.oracle.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1209925827 19828 80.91.229.12 (4 May 2008 18:30:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 4 May 2008 18:30:27 +0000 (UTC) Cc: emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 04 20:31:03 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 1JsizF-0001qZ-4f for ged-emacs-devel@m.gmane.org; Sun, 04 May 2008 20:31:01 +0200 Original-Received: from localhost ([127.0.0.1]:38011 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JsiyX-0005dV-K0 for ged-emacs-devel@m.gmane.org; Sun, 04 May 2008 14:30:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JsiyT-0005d7-BA for emacs-devel@gnu.org; Sun, 04 May 2008 14:30:13 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JsiyS-0005ck-Ez for emacs-devel@gnu.org; Sun, 04 May 2008 14:30:12 -0400 Original-Received: from [199.232.76.173] (port=59170 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JsiyS-0005cc-Ce for emacs-devel@gnu.org; Sun, 04 May 2008 14:30:12 -0400 Original-Received: from mtaout7.012.net.il ([84.95.2.19]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JsiyS-0004TR-EK for emacs-devel@gnu.org; Sun, 04 May 2008 14:30:12 -0400 Original-Received: from HOME-C4E4A596F7 ([84.229.228.217]) by i-mtaout7.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0K0C0006FVXG55F1@i-mtaout7.012.net.il> for emacs-devel@gnu.org; Sun, 04 May 2008 21:12:52 +0300 (IDT) In-reply-to: <004201c8adc1$7caec120$0200a8c0@us.oracle.com> X-012-Sender: halo1@inter.net.il X-detected-kernel: by monty-python.gnu.org: Solaris 10 (1203?) 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:96444 Archived-At: > From: "Drew Adams" > Cc: > Date: Sun, 4 May 2008 01:33:10 -0700 > > > 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. Yes, because the calling code is platform-independent. > 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. > 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. > > 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 It misbehaves when it behaves against your expectations as a Windows user who knows that there's only one system-wide buffer called ``clipboard''. > They are meaningless on Windows. I didn't say they were meaningless. > (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.] x-selection-exists-p is implemented for Windows on w32select.c. And no, it isn't contrary to the comment, because we don't compile Emacs on Windows --without-x. --without-x produces an Emacs that supports only a text terminal, i.e. the -nw operation only. > However, on Windows, w32-win.el calls `menu-bar-enable-clipboard' (at top-level, Yes, because that's what Windows users expect. > 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. > 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. > I imagine there is a good reason for doing things the way they are done, but > it's not clear to me. The only good reason I know of is that it makes the Windows port behave similarly to Emacs on X wrt this feature. (Assuming that we are still talking about Windows, that is.)