Mysterious differences in nsselect.m

Mysterious differences in nsselect.m

[Stefan Monnier]

Could someone explain to me why we have both "ns-own-selection-internal"
and "ns-store-selection-internal"?

They both end up calling ns_string_to_pasteboard_internal, but one with
a nil gtype and the other with a NSStringPboardType gtype, so it seems
that in the case of ns-store-selection-internal we set the "pasteboard"
for all selection types, where in the case of ns-own-selection-internal
we only set the pasteboard for the NSStringPboardType type.

FWIW, I don't know what it means to set a pasteboard for a particular
selection type, nor to set it for all selection types.

Would it be OK to drop ns-store-selection-internal and only use
ns-own-selection-internal instead?


        Stefan

Re: Mysterious differences in nsselect.m

[Jan Djärv]

Hi.

> 19 okt 2014 kl. 00:16 skrev Stefan Monnier <monnier@iro.umontreal.ca>:
> 
> 
> Could someone explain to me why we have both "ns-own-selection-internal"
> and "ns-store-selection-internal"?
> 
> They both end up calling ns_string_to_pasteboard_internal, but one with
> a nil gtype and the other with a NSStringPboardType gtype, so it seems
> that in the case of ns-store-selection-internal we set the "pasteboard"
> for all selection types, where in the case of ns-own-selection-internal
> we only set the pasteboard for the NSStringPboardType type.

If you examine this, you see that "all selection types", i.e. ns_send_types is an array with one member, NSStringPboardType.  So both cases are in practice the same.  I don't know if the original author intended to add more pboard types.  Emacs could in principle send filenames or URL:s from a dired buffer.  But for now Emacs only set strings.

> 
> FWIW, I don't know what it means to set a pasteboard for a particular
> selection type, nor to set it for all selection types.

Its typed data.  You tell the the pasteboard what data to expect, i.e. NSStringPboardType,
NSFilenamesPboardType, NSURLPboardType and so on.

First you declare a pasteboard (ns_symbol_to_pb), like CLIPBOARD, PRIMARY.
Then you tell it what types of data to expect, [pb declareTypes: ns_send_types owner: NSApp];
Then actually transfer data,  [pb setString: nsStr forType: type];

> 
> Would it be OK to drop ns-store-selection-internal and only use
> ns-own-selection-internal instead?

I guess so, but there are other differences.  ns-own-selection-internal runs Vns_sent_selection_hooks and store the selection in Vselection_alist.  
ns-store-selection-internal don't.  

It seems that ns-own-selection-internal is the way it is to go together with
ns-disown-selection-internal and ns-selection-owner-p.

Disown and owner-p does not really exist on NS, you just set data and that is it.
own stores data in Vselection_alist so that disown and owner-p can emulate the X
versions.  Some experimentation shows that owner-p does not work well.
Ypu can select text in Emacs and owner-p return nil, even if x-get-selection-internal returns the very text you selected.

Maybe we should just make disown and owner-p always return nil and skip Vselection_alist.
What parts of Emacs use owner-p?

	Jan D.

Re: Mysterious differences in nsselect.m

[Adrian Robert]

Just to add something about the history that may or may not be informative, the "-store-selection-internal" version was originally part of a whole suite of functions pertaining to “cut buffers”, which appear to be an older X implementation of selection that emacs supported for a while.  I wanted to refactor them out a while back but could not figure out how to do it cleanly.  Only ns-store-selection-internal and ns-get-selection-internal remain now.  If Emacs itself still has multiple selection implementations for X, then we need to keep these for parallelism, but if the older code is finally gone I would think this could be cleaned up too.

-Adrian


On 2014.10.19, at 11:13, Jan Djärv <jan.h.d@swipnet.se> wrote:

> Hi.
> 
>> 19 okt 2014 kl. 00:16 skrev Stefan Monnier <monnier@iro.umontreal.ca>:
>> 
>> 
>> Could someone explain to me why we have both "ns-own-selection-internal"
>> and "ns-store-selection-internal"?
>> 
>> They both end up calling ns_string_to_pasteboard_internal, but one with
>> a nil gtype and the other with a NSStringPboardType gtype, so it seems
>> that in the case of ns-store-selection-internal we set the "pasteboard"
>> for all selection types, where in the case of ns-own-selection-internal
>> we only set the pasteboard for the NSStringPboardType type.
> 
> If you examine this, you see that "all selection types", i.e. ns_send_types is an array with one member, NSStringPboardType.  So both cases are in practice the same.  I don't know if the original author intended to add more pboard types.  Emacs could in principle send filenames or URL:s from a dired buffer.  But for now Emacs only set strings.
> 
>> 
>> FWIW, I don't know what it means to set a pasteboard for a particular
>> selection type, nor to set it for all selection types.
> 
> Its typed data.  You tell the the pasteboard what data to expect, i.e. NSStringPboardType,
> NSFilenamesPboardType, NSURLPboardType and so on.
> 
> First you declare a pasteboard (ns_symbol_to_pb), like CLIPBOARD, PRIMARY.
> Then you tell it what types of data to expect, [pb declareTypes: ns_send_types owner: NSApp];
> Then actually transfer data,  [pb setString: nsStr forType: type];
> 
>> 
>> Would it be OK to drop ns-store-selection-internal and only use
>> ns-own-selection-internal instead?
> 
> I guess so, but there are other differences.  ns-own-selection-internal runs Vns_sent_selection_hooks and store the selection in Vselection_alist.  
> ns-store-selection-internal don't.  
> 
> It seems that ns-own-selection-internal is the way it is to go together with
> ns-disown-selection-internal and ns-selection-owner-p.
> 
> Disown and owner-p does not really exist on NS, you just set data and that is it.
> own stores data in Vselection_alist so that disown and owner-p can emulate the X
> versions.  Some experimentation shows that owner-p does not work well.
> Ypu can select text in Emacs and owner-p return nil, even if x-get-selection-internal returns the very text you selected.
> 
> Maybe we should just make disown and owner-p always return nil and skip Vselection_alist.
> What parts of Emacs use owner-p?
> 
> 	Jan D.
> 
> 

Re: Mysterious differences in nsselect.m

[Stefan Monnier]

> If you examine this, you see that "all selection types", i.e. ns_send_types
> is an array with one member, NSStringPboardType.  So both cases are in
> practice the same.

Aha!

> But for now Emacs only set strings.

Good enough for me.

>> FWIW, I don't know what it means to set a pasteboard for a particular
>> selection type, nor to set it for all selection types.
> Its typed data.  You tell the the pasteboard what data to expect,
> i.e. NSStringPboardType, NSFilenamesPboardType, NSURLPboardType and
> so on.

What I mean is: if you push to the clipboard a string "hello" and then
a filename "/a/b", are they still both in there, or does the second
replace the first?

If the second replaces the first then the loop in
ns_string_to_pasteboard_internal makes no sense, but if they both stay
in there, then it basically means we have several clipboards, so we may
miss one application's clipboard data simply because we don't request
the right type.

> It seems that ns-own-selection-internal is the way it is to go together with
> ns-disown-selection-internal and ns-selection-owner-p.

Indeed.

> Disown and owner-p does not really exist on NS, you just set data and
> that is it.  own stores data in Vselection_alist so that disown and
> owner-p can emulate the X versions.  Some experimentation shows that
> owner-p does not work well.

IIUC the only place we use owner-p is for some corner case of
select-active-region (hence only with the PRIMARY, not with CLIPBOARD),
so it's probably not super important.

> What parts of Emacs use owner-p?

IIRC the only existing call is in deactivate-mark.

Adrian Robert wrote:
> Just to add something about the history that may or may not be informative,
> the "-store-selection-internal" version was originally part of a whole suite
> of functions pertaining to “cut buffers”, which appear to be an older
> X implementation of selection that emacs supported for a while.  I wanted to
> refactor them out a while back but could not figure out how to do it
> cleanly.  Only ns-store-selection-internal and ns-get-selection-internal
> remain now.  If Emacs itself still has multiple selection implementations
> for X, then we need to keep these for parallelism, but if the older code is
> finally gone I would think this could be cleaned up too.

Thanks.  I'm about to install a patch that will remove
ns-store-selection-internal and ns-get-selection-internal and use
ns-own-selection and ns-get-selection instead.  This may break some
things (while ns-own-selection and ns-get-selection seem to be the more
"complex/fancy/complete" implementation, they're also the one that's
been less used since kill/yank has used ns-store-selection-internal and
ns-get-selection-internal until now), tho.


        Stefan

Re: Mysterious differences in nsselect.m

[Jan Djärv]

Hello.

> What I mean is: if you push to the clipboard a string "hello" and then
> a filename "/a/b", are they still both in there, or does the second
> replace the first?

If they are different types, they both are in there.  The idea is that the receiver can request different formats according to his needs, i.e. plain text, HTML, GIF.  There is also a protocol so the owner can be notified about what the receiver wants and then produce that format on the fly.  But Emacs only pushes strings, so they are replaced.

> 
> If the second replaces the first then the loop in
> ns_string_to_pasteboard_internal makes no sense, but if they both stay
> in there, then it basically means we have several clipboards, so we may
> miss one application's clipboard data simply because we don't request
> the right type.

If we where copying a filename for example, we would in that loop push a filename and a string.  String makes sense for a text editor, filename more for a filebrowser.
But I think it was intended for "future use".

	Jan D.