Re: x-selection-exists-p vs x-get-selection

[Eli Zaretskii]

> From: "Drew Adams" <address@hidden>
> Cc: <address@hidden>
> 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.)