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

Previous Next

Full log

View this message in rfc822 format

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
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 16:12:54 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

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

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

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

Previous Next

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