Re: GUI X-FreeDesktop integration

[Eli Zaretskii]

> From: chad <yandros@gmail.com>
> Date: Fri, 28 May 2021 11:49:25 -0700
> Cc: Peter Oliver <p.d.oliver@mavit.org.uk>,
>  EMACS development team <emacs-devel@gnu.org>
> 
>  I don't see how you can make that conclusion with such certainty.  Not
>  all the applications behave in that way, so it's quite possible that
>  people don't expect every application to do it.  Thus, it isn't a
>  catastrophe that Emacs behaves like it does, and like it did until
>  now.
> 
> My experience with a spread of users who use gui launchers of this sort is 
> that they expect exactly what
> Peter suggested, and find the current behavior to be obviously broken. I 
> mention this because that feedback
> is uniform, to the point that people pass around their own home-grown 
> versions of the change suggested
> here, and they uniformly replace the emacs gui launcher entry, rather than 
> supplement it. Multiple times, I
> have seen this exchange prompted by a feelign of disbelief that emacs "still 
> can't open new windows
> instead", followed by the home-grown alternatives. Another common variant is 
> people claiming that Emacs is
> "incompatible" with gui launchers, with a similar "it can, but you have to 
> fix the defaults" reply. Of course, this
> is all anecdotal, and it's a little old at this point as I've had very little 
> exposure to a wide user-base in the past
> year-point-five, but I suggest that this is a good use of the "try it for a 
> while and see" strategy rather than the
> "ultra-conservative" approach. To be more specific, it seems pretty easy to 
> make the standard behavior the
> default, and include an option that retains emacs's older behavior, and see 
> which the distros prefer. We
> could also try asking them directly, if we think we have enough contacts 
> there.

I suggest to do this the other way around: make this new behavior
optional, until we are sure people expect that.

Don't forget that client-based sessions behave differently from
"normal" sessions: "C-x C-c" doesn't exit Emacs, activating a
minibuffer in one frame will prevent input on other frames, etc.  This
is peculiar to Emacs; other applications don't have these potentially
confusing aspects, they just open a new app window (and then users
close them by the mouse, unlike typical Emacs usage).

IOW, client-driven sessions are not exactly what people are used to
with other applications that open a new window instead a new instance.
As usual, we are trying to pretend that some feature peculiar to Emacs
that doesn't really have an equivalent in other applications is and
should be used like some similar feature in other programs.  We tweak
Emacs behavior and use patterns to support the pretense, but doing so
doesn't make the differences go away.  We shouldn't bend our thinking
like that, just because we see some trend in other applications and
think we can easily follow it with something similar.

> Since you asked for opinions.... I suspect the issue is relatively niche. 
> Several years ago, when I was heavily
> involved in supporting a large user base (MIT students, faculty, and staff), 
> the fact that clicking the
> launcher-app multiple times got multiple separate emacsen was considered a 
> bug that got reported relatively
> frequently. The people who wanted multiple isolated emacsen were after very 
> specific outcomes, knew how
> to get there, and (for the vast majority) weren't using the gui launcher to 
> get there. My instinct is that many
> people are in that same situation today, but I might be wrong about that.

Then please explain to me why the time it takes Emacs to start is
still such a hot topic, on Redit, help-gnu-emacs and elsewhere.  That
clearly indicates that people do start Emacs many times, instead of
having a single long-running session.