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

From: Po Lu <[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, which
makes not a whit of a difference in actually running Emacs.  At any
rate, this sentiment is everywhere to be found in on-line Emacs forums
and chatrooms, and you need look no further than the popularity of the
Carbon Emacs port, which is integrated with the Mac OS dictionary, share
dialog, and animation framework.  Minor frivolities such as this do play
an active role in enticing users to proprietary operating systems, and
we cannot be consistent without categorically refusing to endorse them.

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

>> (In fact I've lately discovered that it is FreeDOS where the Emacs
>> port is most useful, and that operating system is 100% Free
>> Software.)
>
> Try to count how many users of DJGPP Emacs actually do that on
> FreeDOS.

[...]

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

>> > 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?  POSIX standardizes no windowing
system, and those POSIX-portable windowing systems which Emacs does
support on GNU/Linux systems are equally functional on Mac OS, not to
mention such non-POSIX systems as OpenVMS, and even MS-DOS.

>> We are speaking of user-visible productivity features provided by
>> the GUI, not internal porting details, and I find it difficult to
>> accept that a one-click interface to "cloud" file storage and to the
>> iPhone Simulator is fundamental to Emacs's architecture or way of
>> life, as it were.
>
> 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.

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