From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Bloat in the Emacs Windows package Date: Fri, 19 Apr 2019 10:00:41 +0300 Message-ID: <83lg06cwdi.fsf@gnu.org> References: <83ftqgg00t.fsf@gnu.org> <83bm14fvxj.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="268914"; mail-complaints-to="usenet@blaine.gmane.org" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: =?utf-8?Q?Bj=C3=B6rn?= Lindqvist Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 19 09:01:44 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hHNWp-0017rQ-Rl for ged-emacs-devel@m.gmane.org; Fri, 19 Apr 2019 09:01:43 +0200 Original-Received: from localhost ([127.0.0.1]:52451 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hHNWo-0003bt-Se for ged-emacs-devel@m.gmane.org; Fri, 19 Apr 2019 03:01:42 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:44116) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hHNWG-0003bc-G9 for emacs-devel@gnu.org; Fri, 19 Apr 2019 03:01:09 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45760) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hHNW8-0006P3-EF; Fri, 19 Apr 2019 03:01:02 -0400 Original-Received: from [176.228.60.248] (port=4474 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hHNW6-0007lj-Hl; Fri, 19 Apr 2019 03:00:59 -0400 In-reply-to: (message from =?utf-8?Q?Bj=C3=B6rn?= Lindqvist on Fri, 19 Apr 2019 00:02:55 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:235643 Archived-At: > From: Björn Lindqvist > Date: Fri, 19 Apr 2019 00:02:55 +0200 > Cc: Stefan Monnier , emacs-devel@gnu.org > > > And btw, invoking through a batch file is in no way 100% transparent. > > For example, I think users who start Emacs from MSYS Bash will have to > > go through cmd.exe, because Bash cannot interpret batch files > > directly. So we will have to provide both a batch file and a Unix > > shell script, at least. > > That's true so a batch file is no good. But isn't the runemacs.exe > file already handling the indirection? If that file is compiled with > CHOOSE_NEWEST_EXE defined, then it will automagically choose the most > recent emacs*.exe if multiple version are installed in the same > directory. First, runemacs.exe is by default _not_ compiled with CHOOSE_NEWEST_EXE defined. I don't think we should turn that feature on by default, because the result might be unpredictable: no one can guarantee that the newest emacs*.exe is what the user wants. E.g., what if some older version is rebuilt and re-installed, or if the user downloads and installs an executable from another source whose timestamp is older? This kind of stuff is not for the faint at heart, IMO, and that's why it's turned off. > Personally, I never run the emacs.exe nor emacs-xy.z.exe directly > because it opens up a useless cmd.exe window. Not if you invoke it from a cmd.exe window. And that is an important, albeit relatively rarely used feature, because it allows several important use cases, such as: . using Emacs in -batch mode . starting Emacs from emacsclient . starting "emacs -Q" to test if some problem happens then . if Emacs crashes, the backtrace is printed on the console as well, which is more visible than when you invoke via runemacs > Instead I use runemacs.exe from the Start menu and emacsclientw.exe > from the Explorer shell. There are use cases beyond those covered by what you describe. E.g., emacsclientw is inappropriate when Emacs is to be called from a program that must wait for Emacs to finish editing, like when it is used as EDITOR from the various VCS programs.