From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: GUI X-FreeDesktop integration Date: Fri, 28 May 2021 22:16:30 +0300 Message-ID: <83mtse7jox.fsf@gnu.org> References: <7f52af92-4fb5-74b4-232a-eabfa315ac0@froglet.home.mavit.org.uk> <8335u9bsc5.fsf@gnu.org> <983c9c1-668f-4b82-896-9d41abfef910@froglet.home.mavit.org.uk> <834ken80xt.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34451"; mail-complaints-to="usenet@ciao.gmane.io" Cc: p.d.oliver@mavit.org.uk, emacs-devel@gnu.org To: chad Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 28 21:17:02 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lmhyg-0008hS-57 for ged-emacs-devel@m.gmane-mx.org; Fri, 28 May 2021 21:17:02 +0200 Original-Received: from localhost ([::1]:33044 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lmhye-0004OZ-33 for ged-emacs-devel@m.gmane-mx.org; Fri, 28 May 2021 15:17:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55346) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lmhy6-0003in-DJ for emacs-devel@gnu.org; Fri, 28 May 2021 15:16:26 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:39904) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lmhy5-0004j3-Oq; Fri, 28 May 2021 15:16:25 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3467 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lmhy5-0002mT-Bh; Fri, 28 May 2021 15:16:25 -0400 In-Reply-To: (message from chad on Fri, 28 May 2021 11:49:25 -0700) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:270020 Archived-At: > From: chad > Date: Fri, 28 May 2021 11:49:25 -0700 > Cc: Peter Oliver , > EMACS development team > > 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.