GNU bug report logs - #76120
[PATCH] Expose the native sharing dialog (macOS)

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: bjorn.bidar <at> thaodan.de, alvaro <at> xenodium.com, stefankangas <at> gmail.com, 76120 <at> debbugs.gnu.org
Subject: bug#76120: [PATCH] Expose the native sharing dialog (macOS)
Date: Thu, 13 Feb 2025 09:44:52 +0200

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: Björn Bidar <bjorn.bidar <at> thaodan.de>,
>   76120 <at> debbugs.gnu.org,
>   alvaro <at> xenodium.com,  stefankangas <at> gmail.com
> Date: Thu, 13 Feb 2025 09:07:49 +0800
> 
> I won't object to implementing Bluetooth "sharing", since a file can
> easily be sent through e.g. blueman-sendto, but I will object to the
> dialog proposed by the OP.  Contrasting the facilities exposed by this
> dialog with their GNU/Linux equivalents is beside the point of our
> policy against features which place proprietary systems at an advantage,
> because our object in doing so is to prevent the creation of any
> material incentive in Emacs that might motivate users to install Mac OS,
> not simply to guarantee that Emacs on Mac OS holds no advantage in raw
> capabilities over Emacs on free systems.  I say this dialog is certainly
> such an incentive, as attested by the existence of this patch rather
> than a patch adding aliases from xdg-open and blueman to AppleScript
> workalikes.  You and I may not be vain enough for such features to
> influence our preferences as regards operating systems, but you cannot
> deny that people exist whom they do influence.
> 
> What is more, half of the dialog is devoted to Apple's proprietary file
> sharing protocol, AirDrop.  Any person can see the folly in providing a
> direct interface to a proprietary file sharing system in Emacs, never
> mind such a file sharing system as is only available on one brand of
> computer.  And it breaks the GNUstep build, though that is the least of
> our concerns.
> 
> Just my two cents.

Thanks, noted.  I stand by my opinion that there's nothing here that's
against our policies.

The issues you mention are very minor and insignificant; if we start
judging changes by these intimate details, we will eventually conclude
that many features we use on non-Posix platforms should be thrown
away, and perhaps that Emacs cannot be reasonably usable on those
platforms at all.  E.g., isn't using the system messages in a separate
thread to implement the input subsystem on MS-Windows also "direct
interface to proprietary mechanisms"?  Or using SuspendThread and
ResumeThread to emulate Posix signal handling on Windows?  Or even
interfacing with DPMI to allow Emacs run as a 32-bit process with
memory protection on top of 16-bit DOS that has no memory protection
at all?

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.