Subject: Re: bug#76120: [PATCH] Expose the native sharing dialog (macOS)

From: Eli Zaretskii <[email-masked]>
Date: Mon, 10 Feb 2025 16:31:22 +0200

> From: Alvaro Ramirez <[email-masked]>
> Cc: Björn Bidar <[email-masked]>,
>   [email-masked],
>   [email-masked]
> Date: Mon, 10 Feb 2025 14:09:35 +0000
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> > I think we should get our terminology right, because the "share"
> > business is replete with hype which muddies the waters.  In
> > particular, quite a few "sharing" options are another word with 
> > "open
> > with", and we already have that (see my other message 
> > up-thread).
> > Examples:
> >
> >   . "sharing" with a printer means printing, which is the same 
> >   as
> >     "opening" by a printer
> >   . "sharing" with an email program means sending as an email 
> >   message,
> >     which is the same as "opening" by a MUA
> >   . "sharing" a selection of text is the same a drag-n-drop the 
> >   text
> >     onto an application
> >
> > etc., etc.  So what exactly is the "sharing" we are talking 
> > about
> > here?  I very much hope that it doesn't just mean show a menu 
> > whose
> > caption says "Share with" (which would mean it's another 
> > hype)...
> 
> Thanks for highlighting this Eli. "Sharing" is indeed an 
> overloaded term and can invite unrelated discussion.
> 
> What's available in this macOS dialog is a context menu of 
> sorts. It more or less aggregates "open with", "send to", or "drag 
> and drop" for external (non-Emacs) applications.
> 
> My initial integration approached things by enumerating available 
> context actions from the system and pipe through existing Emacs 
> infrastructure (context-menu-mode or completing-read). However, 
> this route is a dead end on macOS as the API is now deprecated 
> https://developer.apple.com/documentation/appkit/nssharingservice/sharingservices(foritems:)?language=objc 
> in favor of using the picker dialog 
> https://developer.apple.com/documentation/appkit/nssharingservicepicker?language=objc 
> which is included in the current proposal.

Does an application have any control which contacts are shown in this
dialog?  If so, then I think you could make this dialog pop up as one
(system-specific) selections in the existing Emacs context menu, and
remove from the list the contacts that are already available in the
existing context menu.  If the application cannot control that list, I
think it's very bad, because it would mean the same contact will
appear more than once under different names.