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

From: Eli Zaretskii <[email-masked]>
Date: Thu, 13 Feb 2025 12:17:57 +0200

> From: Po Lu <[email-masked]>
> Cc: [email-masked],  [email-masked],  [email-masked],
>   [email-masked]
> Date: Thu, 13 Feb 2025 17:47:03 +0800
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> >> From: Po Lu <[email-masked]>
> >> Cc: [email-masked],  [email-masked],  [email-masked],
> >>   [email-masked]
> >> Date: Thu, 13 Feb 2025 16:12:54 +0800
> >> 
> >> Eli Zaretskii <[email-masked]> writes:
> >> 
> >> But we're not judging features by intimate details, and we won't have to
> >> remove the MS-Windows or DJGPP ports, because they create no incentive
> >> for users to migrate to MS-Windows or MS-DOS, in contrast to user-facing
> >> amenities provided by the operating system's GUI.
> >
> > That's your opinion, and you are entitled to it.  But it doesn't mean
> > it is universally true: how can we know what does and doesn't give
> > users incentives?
> >
> > I'm having hard time to believe that seeing "Share" is such an
> > incentive.
> 
> I'm sure you'll agree that it is much more plausible for this to be an
> incentive than for a choice of thread library or DOS extender

No, I don't agree.  They are of the same plausibility.

> And no, personally, I would not be moved by a Share dialog.

Then why assume others will be?

> >> We decide whether to reject features by the probability that they
> >> will induce users to another, proprietary, operating system.  The
> >> fact that Emacs's GUI backend executes in threads created by
> >> proprietary C runtime alone is clearly not applicable to this
> >> criterion, but GUI file sharing capabilities are.  The rather when
> >> they amount to an endorsement of a proprietary file sharing service.
> >
> > You are being subjective here because you want to make a point.
> 
> Then, in the spirit of your question above, I ask, how many people will
> agree that being able to link Emacs against a particular C runtime and
> threading library will prepossesses users towards a new operating
> system?

I don't see the relevance, sorry.

> >> > Emacs's architecture and expectations from the underlying platform are
> >> > so Posix-centric that emulating them without resorting to proprietary
> >> > system-specific mechanisms is practically impossible.  Anyone who
> >> > demands us to avoid such interfaces and mechanisms basically tells us
> >> > to stop supporting those systems in a way that makes Emacs useful and
> >> > its features reasonably portable.
> >> 
> >> Mac OS is a POSIX system, just as much as GNU/Linux, if not more.
> >
> > Not in its GUI system.
> 
> If so, how is POSIX relevant at all?

The assumptions made by Emacs about the GUI system basics are
relevant.

> > It is neither fundamental nor an incentive to migrate.
> 
> The implication I was addressing was that a Share dialog could be
> equally fundamental to Emacs as the POSIX `open' or `fstat' system
> calls.  Moreover, it _is_ capable of being such an incentive, or this
> patch would not exist.

This patch adds to Emacs platform-specific means to "open" stuff,
that's all.

> > So let's drop this futile argument, okay?  We have gobs of real work
> > on our hands.
> 
> The easiest means of doing this would be to shelve this proposal till a
> comparable file-sharing system appears on the X desktop.

I'm not willing to shelve it because I see no reason for that.  As
already explained in this too-long dispute.  Please accept that, even
if you disagree.