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

Previous Next

Package: emacs;

Reported by: Álvaro Ramírez <alvaro <at> xenodium.com>

Date: Fri, 7 Feb 2025 15:00:02 UTC

Severity: wishlist

Tags: patch

Full log


Message #223 received at 76120 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#76120: [PATCH] Expose the native sharing dialog (macOS)
Date: Thu, 13 Feb 2025 22:59:18 +0800
Eli Zaretskii <eliz <at> gnu.org> writes:

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

After what I have seen among Macintosh users, I cannot agree.  How
otherwise do you account for the popularity of the Carbon Emacs port
which does already provide such OS interfaces and is frequently
recommended on the strength of this "added value" alone?

> Then why assume others will be?

Because there is abundant evidence of this in this thread, and
elsewhere?

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

I simply restated the postulate which you used to equate this dialog box
with the MS-DOS and MS-Windows ports, which scarcely provide any
material advantage over Emacs on free desktop systems.  Windows NT's
threads or DPMI are implementation details, not advantages, and the only
program from which users could be enticed to the DJGPP port is EDIT.COM.

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

A Share dialog without which Emacs has fared satisfactorily on Mac OS
for upwards of a decade cannot properly be said to be part of its
"basics", I should think.

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

In such a convenient manner as is not yet possible in GNU/Linux systems.
Mac OS users are _already_ able to open files as on free systems by
executing the `open' command in a subprocess, which is functionally
identical to `xdg-open'.  There are no grounds on which to go any
further.

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

I cannot accept this--it amounts to overt if well-intentioned sabotage
of the GNU project's raison d'etre.  It is widely known that AirDrop is
as thoroughly restrictive as the rest of Apple's computer services, and
it is additionally an engine of grotesque censorship, with which every
move towards reconciliation renders it more difficult to improve and
promote Emacs in good conscience, and by putting across the reasoning
behind my protests, I hope to enable others to explain why this is so
more effectively than I can.




This bug report was last modified 20 days ago.

Previous Next


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