From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Caldwell Newsgroups: gmane.emacs.devel Subject: Re: Mac OS X GNU Emacs Installer (make-package) Date: Sat, 30 Nov 2002 15:50:35 -0800 Sender: emacs-devel-admin@gnu.org Message-ID: <2147483647.1038671435@[10.0.0.2]> References: <2ABC8327-04BA-11D7-AADA-00039390AB82@mac.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1038700322 7781 80.91.224.249 (30 Nov 2002 23:52:02 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 30 Nov 2002 23:52:02 +0000 (UTC) Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18IHOy-00021B-00 for ; Sun, 01 Dec 2002 00:52:00 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18IHXF-0000H4-00 for ; Sun, 01 Dec 2002 01:00:33 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 18IHOI-0007ts-00; Sat, 30 Nov 2002 18:51:18 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18IHN9-0006Jq-00 for emacs-devel@gnu.org; Sat, 30 Nov 2002 18:50:07 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18IHN7-0006E0-00 for emacs-devel@gnu.org; Sat, 30 Nov 2002 18:50:06 -0500 Original-Received: from [65.211.227.66] (helo=control2.indigita.com) by monty-python.gnu.org with esmtp (Exim 4.10) id 18IHN6-00063h-00 for emacs-devel@gnu.org; Sat, 30 Nov 2002 18:50:04 -0500 Original-Received: from [10.0.0.2] (sc-24-30-184-132.socal.rr.com [24.30.184.132]) (authenticated (0 bits)) by control2.indigita.com (8.11.0/8.11.0/Debian 8.11.0-6) with ESMTP id gAUNnv131097 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (192 bits) verified NO) for ; Sat, 30 Nov 2002 15:50:00 -0800 Original-To: emacs-devel@gnu.org In-Reply-To: <2ABC8327-04BA-11D7-AADA-00039390AB82@mac.com> X-Mailer: Mulberry/3.0.0 (Mac OS X) Content-Disposition: inline Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:9768 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9768 On 11/30/02 3:19 PM -0800 Steven Tamm wrote: > On Saturday, November 30, 2002, at 02:48 PM, David Caldwell wrote: > >> On 11/30/02 2:23 PM -0800 Steven Tamm wrote: >> >> I have some patches for make-package as well. Should I send them to >> the list? > > Yes, please. Ok. I'll do so shortly. >> The second one is more controversial, I think. I made a little shell >> wrapper that launches the Emacs.app so that typing plain "emacs" in >> the shell doesn't segfault. Since the user should be free to move his >> /Applications/Emacs.app around as he sees fit, I can't call that >> wrapper. So I made a duplicate app wrapper in libexec. I hard linked >> it to the emacs exe in /Applications/Emacs.app so it doesn't take up >> any more room in the disk image, nor on the system. It has complete >> transparency to the user, I think. > > This is the solution that Andrew proposes. /usr/local/bin/emacs would be > a shell script that calls /usr/local/bin/emacs-21.3.50 -nw $*. I don't > like that solution very much. This is a patch I placed on the list > earlier; it causes the executable to determine if it is inside an > application bundle. If it is not, it will cause it to > inhibit_windowing_system. I placed the call to this right after the call > to init_mac_osx_environment inside emacs.c:main [..] That was my initial idea. But in the end I like the way the shell script works better. Typing plain "emacs" gives you a new window, while "emacs -nw" gives you the console. It works just like under X Windows. Otherwise there is no way to get a nice window from the command line, except by writing your own shell wrapper. To me that is the only reason to choose the shell script road over the patch you propose (Although I think patch should be there as well, since emacs should never segfault). > BTW, I think making Contents/MacOS/Emacs be a hard link to emacs-21.3.50 > is a bad idea. The Application may (and in my case usually will) live on > a different volume than the /usr/local tree. I'll keep the symlink > option there for the Application, but remove the bad behavior. The question is, does the installer (or pax) automatically copy the file if it's getting unloaded accross filesystems? If so then there's no problem with a hard link. -David