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

[Drew Adams]

> > 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))))