GNU bug report logs -
#76120
[PATCH] Expose the native sharing dialog (macOS)
Previous Next
Full log
Message #220 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: bjorn.bidar <at> thaodan.de, 76120 <at> debbugs.gnu.org, alvaro <at> xenodium.com,
> stefankangas <at> gmail.com
> Date: Thu, 13 Feb 2025 17:47:03 +0800
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Po Lu <luangruo <at> yahoo.com>
> >> Cc: bjorn.bidar <at> thaodan.de, 76120 <at> debbugs.gnu.org, alvaro <at> xenodium.com,
> >> stefankangas <at> gmail.com
> >> Date: Thu, 13 Feb 2025 16:12:54 +0800
> >>
> >> Eli Zaretskii <eliz <at> gnu.org> 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.
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.