x-selection-exists-p vs x-get-selection

x-selection-exists-p vs x-get-selection

[Drew Adams]

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.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sat, 3 May 2008 15:54:46 -0700
> 
> 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.  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.

If you have specific situations where the code using them misbehaves
on Windows, please describe those situations.

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

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 04 May 2008 07:02:42 +0300, Eli Zaretskii <eliz@gnu.org> said:

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

FWIW, macselect.c for the Mac Carbon port is trying to simulate the
semantics on X11 by reusing the most of the code in xselect.c.  On
Mac, there are multiple interapplication storages called "scrap"s, and
the clipboard is actually a particular scrap named
"com.apple.scrap.clipboard".  The selection such as PRIMARY or
SECONDARY may or may not be associated with a scrap.  The association
is made via mac-scrap-name property.

  lisp/term/mac-win.el:

    (put 'CLIPBOARD 'mac-scrap-name "com.apple.scrap.clipboard")
    (when (eq system-type 'darwin)
      (put 'FIND 'mac-scrap-name "com.apple.scrap.find")
      (put 'PRIMARY 'mac-scrap-name
	   (format "org.gnu.Emacs.%d.selection.PRIMARY" (emacs-pid))))

The selection SECONDARY is not associated with any scraps.

The scrap associated with a selection works as a backing store of the
selection.  When Emacs owns such a selection, the data is stored to
the scrap.  When another application set some data to the scrap, Emacs
can retrieve it through the corresponding selection.

A selection that is not associated with any scraps is used inside
Emacs only.  Still one can "own" such a selection.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

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

[Drew Adams]

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

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@ORACLE.COM>
> Cc: <emacs-devel@gnu.org>
> 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.)

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

[Eli Zaretskii]

> Date: Sun, 04 May 2008 15:34:22 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: Drew Adams <drew.adams@oracle.com>,
> 	emacs-devel@gnu.org
> 
> FWIW, macselect.c for the Mac Carbon port is trying to simulate the
> semantics on X11 by reusing the most of the code in xselect.c.  On
> Mac, there are multiple interapplication storages called "scrap"s, and
> the clipboard is actually a particular scrap named
> "com.apple.scrap.clipboard".  The selection such as PRIMARY or
> SECONDARY may or may not be associated with a scrap.

AFAIK, this cannot be done on Windows, since there's only one such
storage buffer, called the clipboard.  Each time you cop or cut text
from some application, the clipboard contents gets automatically
overwritten with the new material.  And there's no meaning to
``owner'' of the clipboard contents, since the stuff is already in the
clipboard and is ``owned'' by the GUI subsystem of the OS.

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

[Jason Rumney]

Eli Zaretskii wrote:
> And there's no meaning to
> ``owner'' of the clipboard contents, since the stuff is already in the
> clipboard and is ``owned'' by the GUI subsystem of the OS.
>   

There are two ways to use the clipboard in Windows. One is to put stuff 
on the clipboard, handing over ownership to Windows. The other is to 
claim ownership of the clipboard, and if and when another program wants 
to paste, you get a message requesting to render the contents to the 
clipboard. Emacs was changed to use the latter method some time ago, as 
it is much more efficient for cases where the clipboard data is only 
ever used inside Emacs.

Also, I think we support primary and secondary selection within Emacs 
even on Windows, but there is no standard way to support this between 
programs (though Cygwin X probably has a convention we could follow if 
someone feels this is important enough to work on).

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

[Drew Adams]

> Also, I think we support primary and secondary selection within Emacs 
> even on Windows,

Thank you. That is what I was talking about. I really don't care much whether it
is officially called a secondary selection on Windows or not. The point is that
it _is_ available to Windows users.

> but there is no standard way to support this between 
> programs (though Cygwin X probably has a convention we could 
> follow if someone feels this is important enough to work on).

Thanks, I didn't know that part. For my purposes, just being able to define it
in Emacs and use it in Emacs (on Windows) is enough. But yes, what you mention
could also be interesting. (Frankly, I've never used the secondary selection
outside Emacs.)

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

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

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 04 May 2008 21:33:16 +0300, Eli Zaretskii <eliz@gnu.org> said:

>> FWIW, macselect.c for the Mac Carbon port is trying to simulate the
>> semantics on X11 by reusing the most of the code in xselect.c.  On
>> Mac, there are multiple interapplication storages called "scrap"s,
>> and the clipboard is actually a particular scrap named
>> "com.apple.scrap.clipboard".  The selection such as PRIMARY or
>> SECONDARY may or may not be associated with a scrap.

> AFAIK, this cannot be done on Windows, since there's only one such
> storage buffer, called the clipboard.

Mac OS 9 also had only one such storage buffer, but the selection
SECONDARY could be "own"ed or "disown"ed.

> Each time you cop or cut text from some application, the clipboard
> contents gets automatically overwritten with the new material.  And
> there's no meaning to ``owner'' of the clipboard contents, since the
> stuff is already in the clipboard and is ``owned'' by the GUI
> subsystem of the OS.

The "owner" of the clipboard means who cleared (and optionally set
data to) the clipboard most recently.

The point of xselect.c and macselect.c is that there are two types of
selection implemantations, local and foreign ones.  The local
selection is just an Emacs internal storage, and the foreign selection
is interapplication storage such as the clipboard.  They share almost
the same set of operations such as owning, disowning, and getting
data.  On Mac, operations on the selection (Emacs symbol) CLIPBOARD
act both on local and foreign selections, and those on the SECONDARY
act on only the local selection because it doesn't have the
corresponding foreign one.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sun, 4 May 2008 16:30:48 -0700
> Cc: emacs-devel@gnu.org
> 
> See, you knew what I meant by "secondary selection" after all.

Since it turns out I had no idea what I was talking about, I will now
stop.  Perhaps someone else who does could help you.