Thread: [Mac-emacs-devel] Re: 'Fatal error (6).Abort' (with fix)
Brought to you by:
akochoi
Menu
▾
▴
mac-emacs-devel
|
From: Steven T. <ste...@ma...> - 2002-08-07 19:14:25
|
The problem is -nw.
I got kind of sick of the whole -nw thing causing a crash from the
command line. So here is a fix. It will only start up the windowing
system if it can find the "CFBundleIdentifier" string in the Info.plist
file. This should only happen if emacs is inside an Emacs.app bundle.
If you start it up from a shell, it won't find the Info.plist file and
will set inhibit_window_system to 1. The cool thing about this setup is
that it takes ignores symbolic links. So you can have the same file be
a windowed app in one place and a command line app in another. This
makes the Emacs application much smaller while still being portable.
Here's what I mean. Suppose you install emacs-21.3.50 in
/usr/local/bin. Then you symbolically link
Emacs.app/Contents/MacOS/Emacs to /usr/local/bin/emacs-21.3.50.
Executing /usr/local/bin/emacs-21.3.50 from a shell will startup in the
terminal.
Executing /Applications/Emacs.app/Contents/MacOS/Emacs from a shell will
startup in the dock with windows.
-Steven
Index: src/emacs.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/emacs.c,v
retrieving revision 1.312
diff -c -r1.312 emacs.c
*** src/emacs.c 15 Jul 2002 00:00:36 -0000 1.312
--- src/emacs.c 7 Aug 2002 19:07:47 -0000
***************
*** 1520,1525 ****
--- 1520,1529 ----
keys_of_window ();
}
+ #if HAVE_CARBON
+ mac_determine_bundle_status();
+ #endif
+
if (!noninteractive)
{
#ifdef VMS
Index: src/macterm.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/macterm.c,v
retrieving revision 1.14
diff -c -r1.14 macterm.c
*** src/macterm.c 4 Aug 2002 19:29:06 -0000 1.14
--- src/macterm.c 7 Aug 2002 19:08:05 -0000
***************
*** 13610,13613 ****
--- 13833,13869 ----
command, this enables the Mac keyboard to be used to enter non-ASCII
characters directly. */);
mac_keyboard_text_encoding = kTextEncodingMacRoman;
+ }
+
+ /* Determine if the executable is not in a bundle, and if so, do not
attempt
+ to start up the window system */
+ void mac_determine_bundle_status()
+ {
+ #if MAC_OSX
+ extern int inhibit_window_system;
+ extern int noninteractive;
+ OSErr err;
+ CFBundleRef appsBundle;
+
+ /* No need to test if already -nw*/
+ if (inhibit_window_system || noninteractive)
+ return;
+
+
+ appsBundle = CFBundleGetMainBundle();
+ if (appsBundle != NULL)
+ {
+ CFStringRef cfBI = CFSTR("CFBundleIdentifier");
+ CFTypeRef res = CFBundleGetValueForInfoDictionaryKey(appsBundle,
cfBI);
+ /* We found the bundle identifier, now we know we are valid. */
+ if (res != NULL)
+ {
+ CFRelease(res);
+ return;
+ }
+ }
+
+ /* Unless we actually find the resource, set -nw */
+ inhibit_window_system = 1;
+ #endif
}
-Steven
|
|
From: Andrew C. <ak...@sh...> - 2002-08-09 01:42:38
|
> The problem is -nw.
>
> I got kind of sick of the whole -nw thing causing a crash from the
> command line. So here is a fix. It will only start up the
> windowing system if it can find the "CFBundleIdentifier" string in
> the Info.plist file. This should only happen if emacs is inside an
> Emacs.app bundle. If you start it up from a shell, it won't find
> the Info.plist file and will set inhibit_window_system to 1. The
> cool thing about this setup is that it takes ignores symbolic links.
> So you can have the same file be a windowed app in one place and a
> command line app in another. This makes the Emacs application much
> smaller while still being portable.
>
> [...]
>
> -Steven
>
> [...]
Hi Steven,
I believe the long-term solution is to install the application bundle
at one place (say /Applications/ or some other location specified by
the user) and have the executable in $prefix/bin/ invoked from the
command line start a GUI or terminal version depending on whether the
-nw switch was used.
For that to work, we need a fix for invoking a GUI version from the
command line. So here it is: the patch at the end of this message
allows a GUI Emacs to be started at the command line, with options
passed to it and all! A pathname to the executable in the bundle must
be typed to the shell for the application to find its resources, of
course. There's still a bit of a problem since input becomes sluggish
when subprocesses are started (say an ftp process). I'll try to find
a fix for this (everyone is welcome to help).
When this works, all we need to do is install something like the
following script as the file /usr/local/bin/emacs.
#!/bin/sh
/Applications/Emacs.app/Contents/MacOS/Emacs $*
Before I work out the changes to the makefiles and so on, I'd like to
make sure everything works (and fix the above bug). Therefore I
invite everyone to test this patch. Thanks.
Andrew.
-----
Index: src/mac.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/mac.c,v
retrieving revision 1.7
diff -u -r1.7 mac.c
--- src/mac.c 2 Aug 2002 20:34:38 -0000 1.7
+++ src/mac.c 9 Aug 2002 00:48:13 -0000
@@ -2745,6 +2745,31 @@
return Qnil;
}
+#ifdef MAC_OSX
+#undef select
+
+extern int inhibit_window_system;
+
+int
+sys_select (n, rfds, wfds, efds, timeout)
+ int n;
+ SELECT_TYPE *rfds;
+ SELECT_TYPE *wfds;
+ SELECT_TYPE *efds;
+ struct timeval *timeout;
+{
+ EventRecord e;
+
+ if (!inhibit_window_system && n == 1 && rfds && FD_ISSET (0, rfds))
+ return 1;
+
+ if (!inhibit_window_system && rfds && FD_ISSET (0, rfds)
+ && EventAvail (everyEvent, &e))
+ return 1;
+
+ return select (n, rfds, wfds, efds, timeout);
+}
+#endif /* MAC_OSX */
void
syms_of_mac ()
Index: src/macterm.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/macterm.c,v
retrieving revision 1.14
diff -u -r1.14 macterm.c
--- src/macterm.c 4 Aug 2002 19:29:06 -0000 1.14
+++ src/macterm.c 9 Aug 2002 00:48:19 -0000
@@ -366,6 +366,7 @@
extern Lisp_Object x_icon_type P_ ((struct frame *));
+extern int inhibit_window_system;
#if __MRC__
QDGlobals qd; /* QuickDraw global information structure. */
@@ -13405,6 +13433,18 @@
return dpyinfo;
}
+#ifdef MAC_OSX
+void MakeMeTheFrontProcess ()
+{
+ ProcessSerialNumber psn;
+ OSErr err;
+
+ err = GetCurrentProcess (&psn);
+ if (err == noErr)
+ (void) SetFrontProcess (&psn);
+}
+#endif /* MAC_OSX */
+
/* Set up use of X before we make the first connection. */
static struct redisplay_interface x_redisplay_interface =
@@ -13514,6 +13554,9 @@
#endif
DisableMenuCommand (NULL, kHICommandQuit);
+
+ if (!inhibit_window_system)
+ MakeMeTheFrontProcess ();
#endif
}
Index: src/s/darwin.h
===================================================================
RCS file: /cvsroot/emacs/emacs/src/s/darwin.h,v
retrieving revision 1.4
diff -u -r1.4 darwin.h
--- src/s/darwin.h 1 Aug 2002 03:33:20 -0000 1.4
+++ src/s/darwin.h 9 Aug 2002 00:48:20 -0000
@@ -308,3 +308,7 @@
#define realloc unexec_realloc
#define free unexec_free
#endif
+
+#if defined (emacs) || defined (temacs)
+#define select sys_select
+#endif
|
|
From: Steven T. <ste...@ma...> - 2002-08-09 08:09:44
|
Andrew - If /usr/local/bin/emacs is a shell forward to Emacs.app/Contents/MacOS/Emacs, then I have no idea what the problem is. On my machine (which may be anomalous), emacs behaves exactly as intended wrt the -nw flag if you start it from a bundle. If you start it from the command-line without -nw, it also works, except that you have to hit return once to get the emacs executable going. So the only thing this patch seems to fix is that you don't have to hit return. That, however, is beyond useful. When 10.2 comes around and the multithreaded UI can be used, a call to add_keyboard_wait_descriptor would fix the select problem that this patch concerns. My only comments about the patch would be: 1. MakeMeTheFrontProcess would be nice to have as a lisp function. 2. mac_do_receive_drag should call MakeMeTheFrontProcess instead of duplicating the code. In any case, I still think my patch is a good idea to prevent a random Emacs executable from trying to use Carbon if it is outside a bundle (and thus can't connect to the window server). But if /usr/local/bin/emacs is going to be a forward to Emacs.app... which will always be in a bundle, then it's not of much use. -Steven P.S. Is the ADC Developer Mailing worth the $199? It seems that for the extra $70 over purchasing jaguar, it may make sense to get a year of updates on disc. |
|
From: <dm...@dm...> - 2002-08-09 08:54:54
|
* ste...@ma... [2002-08-09 06:59:27] > When 10.2 comes around and the multithreaded UI can be used, a call > to add_keyboard_wait_descriptor would fix the select problem that > this patch concerns. Forgive my ignorance, but would this also be an opportunity to make ctrl-g work better ? It's one of main irritations which remains for me. |
|
From: Steven T. <ste...@ma...> - 2002-08-09 16:04:00
|
Yes it would. I'm not sure I've posted this to the list, but it makes sense. The main problem is that C-g does not interrupt synchronous processes. This is because C-g does not generate an interrupt at all. The only way to get keyboard input is to be in a call to WaitNextEvent or ReceiveNextEvent. The carbon event manager allows the event loop to run asynchronously in its own thread, so C-g could be recieved and then passed into emacs-lisp. So in order to fix the problem, we can place event handling in one thread, and the emacs lisp loop in a separate thread. Then when C-g comes into the UI, we can immediately post an interrupt to the lisp loop and it will work just like X windows. However due to other restrictions, this event handling thread can only be the "main" thread. This, I think, is a bug in Mac OS X, but it's documented quite explicitly. In addition, interrupt signals like SIGINT and SIGPIPE are also only sent to the main thread. This means that both the lisp loop and the event loop need to be in the main thread for emacs to work. 10.2 includes thread-specific signal masks (specifically it includes pthread_kill and pthread_). This means that SIGINT and SIGPIPE can be sent to a thread other than the main thread. Therefore in 10.2 (and darwin build 6.0), the Carbon Event Manager's asynchronous event handling can be used and C-g will work like on w32 or x. And emacs will be more efficient and responsive. -Steven On Friday, August 9, 2002, at 01:54 AM, dm...@dm... wrote: > * ste...@ma... [2002-08-09 06:59:27] >> When 10.2 comes around and the multithreaded UI can be used, a call >> to add_keyboard_wait_descriptor would fix the select problem that >> this patch concerns. > > Forgive my ignorance, but would this also be an opportunity to make > ctrl-g work better ? It's one of main irritations which remains for > me. > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Mac-emacs-devel mailing list > Mac...@li... > https://lists.sourceforge.net/lists/listinfo/mac-emacs-devel |
|
From: Andrew C. <ak...@sh...> - 2002-08-11 01:30:13
|
> P.S. Is the ADC Developer Mailing worth the $199? It seems that > for the extra $70 over purchasing jaguar, it may make sense to get a > year of updates on disc. Hi Steven, I had access to these when I was teaching. Either I purchased them for my projects or another project in our department purchased them and allowed me to borrow them. To be honest I didn't find them particularly useful for the development of Emacs. They're indepensible, of course, if you're following Apple's latest software technologies. I spent a lot of time studying OpenDoc :-)! I thought it was the next big time. Shows you how much I know :-). Andrew. |
Thanks for helping keep SourceForge clean.
X