mac-emacs-devel Mailing List for Emacs for Mac OS 8/9 (Page 4)
Brought to you by:
akochoi
Menu
▾
▴
mac-emacs-devel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
(2) |
Mar
(8) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(15) |
Nov
(6) |
Dec
(7) |
| 2002 |
Jan
(5) |
Feb
(1) |
Mar
|
Apr
(1) |
May
(11) |
Jun
(7) |
Jul
(18) |
Aug
(36) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Andrew C. <ak...@sh...> - 2002-02-09 23:25:15
|
> I wonder if you know of anyone that has been working on your patch to
> include X11 support? One of the big reasons to move from emacs20 to
> emacs21 is its improved faces support.
For those who are interested in running Emacs 21.1 on Mac OS X under X
Window, Tsutumo Ikegami has sent in the patch below. Thank you,
Tsutumo!
Andrew.
-----
From: Tsutomu IKEGAMI <ik...@ad...> To:
ak...@cs... Subject: Re: Emacs-21.1 on Mac In-reply-to:
Your message of "Sat, 29 Dec 2001 11:48:50 AST."
<200...@cs...> Date: Thu, 03 Jan 2002
14:24:16 -0400 Sender: ik...@as...
Andrew,
A Happy New Year!
I've played with emacs-21.1. I noticed that 'emacs-21.1.30 -nw'
crashes on C-g after M-x manual-entry command (or, after some
subprocess calls, maybe). The patch at the end is a fix, which is
stolen from emacs-20.7.41 package from darwin project. It works fine
for me.
The patch should be applied after your emacs-21.1-2-mac.patch. I
haven't applied your patch on src/process.c. The patches on
src/macmenu.c and src/macterm.c may be applied.
It also include some fixes for the compilation with X11. To compile
with X11,
(1) ./configure --without-carbon
(2) Modify src/Makefile manually(!) so that X11R6/lib*.a should
be linked instead of lib*.dylib. (Those *.dylibs, prepared
by X on X project, are not prebound. unexmacosx.c cannot
dump.)
Because of (2), the resulting executable is fatty.
Despite my expectation, I still cannot launch Carbon Emacs (build with
./configure --without-x). Again, blank window opens, application icon
continues popping in the Dock, and that's all. I should look into
more detail.
truly yours,
IKEGAMI, Tsutomu
Dep. of Chemistry, UPR
ik...@ad...
----- 8< ---------- 8< ----- snip, snip ----- 8< ---------- 8< -----
diff -aur -x info emacs-21.1.org/src/callproc.c emacs-21.1/src/callproc.c
--- emacs-21.1.org/src/callproc.c Thu Jan 3 12:57:50 2002
+++ emacs-21.1/src/callproc.c Thu Jan 3 01:48:54 2002
@@ -611,7 +611,11 @@
pid = child_setup (filefd, fd1, fd_error, (char **) new_argv,
0, current_dir);
#else /* not WINDOWSNT */
+#ifndef PUMA_VFORK_ISSUES_CLEARED_UP
+ pid = fork ();
+#else
pid = vfork ();
+#endif
if (pid == 0)
{
diff -aur -x info emacs-21.1.org/src/dispextern.h emacs-21.1/src/dispextern.h
--- emacs-21.1.org/src/dispextern.h Thu Jan 3 12:57:36 2002
+++ emacs-21.1/src/dispextern.h Thu Jan 3 02:00:44 2002
@@ -39,7 +39,7 @@
#include "w32gui.h"
#endif
-#if defined (MAC_OS8) || defined (MAC_OSX)
+#ifdef MAC_OS
#include "macgui.h"
#endif
diff -aur -x info emacs-21.1.org/src/getloadavg.c emacs-21.1/src/getloadavg.c
--- emacs-21.1.org/src/getloadavg.c Tue Jun 20 09:17:40 2000
+++ emacs-21.1/src/getloadavg.c Thu Jan 3 01:48:54 2002
@@ -401,7 +401,7 @@
# define host_self mach_host_self
# endif
-# ifdef NeXT
+# if defined(NeXT) || defined(MAC_OSX)
# ifdef HAVE_MACH_MACH_H
# include <mach/mach.h>
# else
@@ -449,7 +449,7 @@
/* Avoid static vars inside a function since in HPUX they dump as pure. */
-# ifdef NeXT
+# if defined(NeXT) || defined(MAC_OSX)
static processor_set_t default_set;
static int getloadavg_initialized;
# endif /* NeXT */
@@ -626,13 +626,15 @@
# endif /* __NetBSD__ */
-# if !defined (LDAV_DONE) && defined (NeXT)
+# if !defined (LDAV_DONE) && (defined (NeXT) || defined(MAC_OSX))
# define LDAV_DONE
/* The NeXT code was adapted from iscreen 3.2. */
+#ifndef MAC_OSX
host_t host;
struct processor_set_basic_info info;
unsigned info_count;
+#endif
/* We only know how to get the 1-minute average for this system,
so even if the caller asks for more than 1, we only return 1. */
@@ -645,6 +647,7 @@
if (getloadavg_initialized)
{
+#ifndef MAC_OSX
info_count = PROCESSOR_SET_BASIC_INFO_COUNT;
if (processor_set_info (default_set, PROCESSOR_SET_BASIC_INFO, &host,
(processor_set_info_t) &info, &info_count)
@@ -655,6 +658,21 @@
if (nelem > 0)
loadavg[elem++] = (double) info.load_average / LOAD_SCALE;
}
+#else
+ struct processor_set_load_info info;
+ host_t host;
+ unsigned info_count = PROCESSOR_SET_LOAD_INFO_COUNT;
+
+ if (processor_set_info (default_set, PROCESSOR_SET_LOAD_INFO, &host,
+ (processor_set_info_t) &info, &info_count)
+ != KERN_SUCCESS)
+ getloadavg_initialized = 0;
+ else
+ {
+ if (nelem > 0)
+ loadavg[elem++] = (double) info.load_average / LOAD_SCALE;
+ }
+#endif
}
if (!getloadavg_initialized)
diff -aur -x info emacs-21.1.org/src/m/powermac.h emacs-21.1/src/m/powermac.h
--- emacs-21.1.org/src/m/powermac.h Thu Jan 3 12:57:37 2002
+++ emacs-21.1/src/m/powermac.h Thu Jan 3 01:48:54 2002
@@ -58,11 +58,11 @@
/* Data type of load average, as read out of kmem. */
-#define LOAD_AVE_TYPE long
+/* #define LOAD_AVE_TYPE long */
/* Convert that into an integer that is 100 for a load average of 1.0 */
-#define LOAD_AVE_CVT(x) (int) (((double) (x)) * 100.0 / FSCALE)
+/* #define LOAD_AVE_CVT(x) (int) (((double) (x)) * 100.0 / FSCALE) */
/* Define CANNOT_DUMP on machines where unexec does not work.
Then the function dump-emacs will not be defined
@@ -119,3 +119,5 @@
If you've just fixed a problem in an existing configuration file,
you should also check `etc/MACHINES' to make sure its descriptions
of known problems in that configuration should be updated. */
+
+#define DATA_SEG_BITS 0
diff -aur -x info emacs-21.1.org/src/md5.h emacs-21.1/src/md5.h
--- emacs-21.1.org/src/md5.h Wed Dec 6 17:16:37 2000
+++ emacs-21.1/src/md5.h Thu Jan 3 01:48:54 2002
@@ -71,7 +71,7 @@
#endif
-#ifndef __GNUC__
+#if !defined(__GNUC__) || defined(MAC_OSX)
#define __attribute__(X)
#define __alignof__(X) 1
#endif
diff -aur -x info emacs-21.1.org/src/process.c emacs-21.1/src/process.c
--- emacs-21.1.org/src/process.c Tue Sep 25 04:21:22 2001
+++ emacs-21.1/src/process.c Thu Jan 3 01:48:54 2002
@@ -1482,7 +1482,11 @@
current_dir = ENCODE_FILE (current_dir);
#ifndef WINDOWSNT
+#ifndef PUMA_VFORK_ISSUES_CLEARED_UP
+ pid = fork ();
+#else
pid = vfork ();
+#endif
if (pid == 0)
#endif /* not WINDOWSNT */
{
diff -aur -x info emacs-21.1.org/src/regex.h emacs-21.1/src/regex.h
--- emacs-21.1.org/src/regex.h Tue Oct 17 02:55:04 2000
+++ emacs-21.1/src/regex.h Thu Jan 3 01:48:54 2002
@@ -533,6 +533,8 @@
# else
# define __restrict
# endif
+# elif defined(MAC_OSX)
+# define __restrict
# endif
#endif
/* For now unconditionally define __restrict_arr to expand to nothing.
diff -aur -x info emacs-21.1.org/src/s/darwin.h emacs-21.1/src/s/darwin.h
--- emacs-21.1.org/src/s/darwin.h Thu Jan 3 12:57:38 2002
+++ emacs-21.1/src/s/darwin.h Thu Jan 3 02:17:35 2002
@@ -39,7 +39,7 @@
/* MAC_OS is used to conditionally compile code common to both MAC_OS8
and MAC_OSX. */
-#ifdef MAC_OSX
+#if defined(MAC_OSX) && !defined(HAVE_X11)
#define MAC_OS
#endif
@@ -48,6 +48,13 @@
#define SYSTEM_TYPE "darwin"
+#undef KERNEL_FILE
+#define KERNEL_FILE "/mach_kernel"
+
+#define HAVE_ALLOCA
+
+#define HAVE_MACH_MACH_H
+
/* NOMULTIPLEJOBS should be defined if your system's shell
does not have "job control" (the ability to stop a program,
run some other program, then continue the first one). */
@@ -76,7 +83,7 @@
to read the input and send it to the true Emacs process
through a pipe. */
-#define INTERRUPT_INPUT 1
+#define INTERRUPT_INPUT
/* Letter to use in finding device name of first pty,
if system supports pty's. 'a' means it is /dev/ptya0 */
@@ -202,7 +209,7 @@
#define __restrict
/* Fix compilation problem for md5.c. */
-#define __attribute__(x)
+/* #define __attribute__(x) */
/* Used in dispnew.c. Copied from freebsd.h. */
#define PENDING_OUTPUT_COUNT(FILE) ((FILE)->_p - (FILE)->_bf._base)
@@ -210,6 +217,16 @@
/* Darwin provides POSIX-style getpgrp. */
#define GETPGRP_NO_ARG
+#define TERMCAP_FILE "/usr/share/misc/termcap"
+
+#define A_OUT_H_FILE <sys/exec.h>
+
+/* Data type of load average, as read out of kmem. */
+#define LOAD_AVE_TYPE long
+
+/* Convert that into an integer that is 100 for a load average of 1.0 */
+#define LOAD_AVE_CVT(x) (int) (((double)(x)) * 100.0 / FSCALE)
+
/* System uses OXTABS instead of the expected TAB3. (Copied from
bsd386.h.) */
#define TAB3 OXTABS
@@ -218,11 +235,17 @@
framework. */
#define SYSTEM_MALLOC
+#define WAIT_USE_INT
+
+#define SOCKLEN_TYPE int
+
/* Define HAVE_SOCKETS if system supports 4.2-compatible sockets. */
#define HAVE_SOCKETS
/* Extra initialization calls in main for Mac OS X system type. */
+#ifndef HAVE_X11
#define SYMS_SYSTEM syms_of_mac()
+#endif
/* Definitions for how to dump. Copied from nextstep.h. */
diff -aur -x info emacs-21.1.org/src/sysdep.c emacs-21.1/src/sysdep.c
--- emacs-21.1.org/src/sysdep.c Thu Jan 3 12:57:38 2002
+++ emacs-21.1/src/sysdep.c Thu Jan 3 01:48:54 2002
@@ -811,7 +811,12 @@
synch_process_alive = 1;
#endif /* __DJGPP__ > 1 */
#else
+#ifndef PUMA_VFORK_ISSUES_CLEARED_UP
+ pid = fork ();
+#else
pid = vfork ();
+#endif
+
if (pid == -1)
error ("Can't spawn subshell");
#endif
diff -aur -x info emacs-21.1.org/src/term.c emacs-21.1/src/term.c
--- emacs-21.1.org/src/term.c Thu Jan 3 12:57:38 2002
+++ emacs-21.1/src/term.c Thu Jan 3 01:48:54 2002
@@ -2191,6 +2191,10 @@
Initialization
***********************************************************************/
+#if defined(__APPLE_CC__)
+__private_extern__ char _emacs_PC;
+#define PC _emacs_PC
+#endif
void
term_init (terminal_type)
char *terminal_type;
diff -aur -x info emacs-21.1.org/src/termcap.c emacs-21.1/src/termcap.c
--- emacs-21.1.org/src/termcap.c Thu Jan 3 12:57:38 2002
+++ emacs-21.1/src/termcap.c Thu Jan 3 01:48:54 2002
@@ -297,9 +297,12 @@
int tputs_baud_rate;
/* Already defined in the System framework in Mac OS X and causes
prebinding to fail. */
-#ifndef MAC_OSX
-char PC;
-#endif /* MAC_OSX */
+#ifdef __APPLE_CC__
+__private_extern__ char _emacs_PC = '\0';
+#define PC _emacs_PC
+#else
+ char PC;
+#endif
#if 0 /* Doesn't seem to be used anymore. */
diff -aur -x info emacs-21.1.org/src/tparam.c emacs-21.1/src/tparam.c
--- emacs-21.1.org/src/tparam.c Thu Jan 3 12:57:38 2002
+++ emacs-21.1/src/tparam.c Thu Jan 3 01:48:54 2002
@@ -107,9 +107,15 @@
/* These are already defined in the System framework in Mac OS X and
cause prebinding to fail. */
-#ifndef MAC_OSX
-char *BC;
-char *UP;
+#ifdef __APPLE_CC__
+__private_extern__ char *_emacs_BC = NULL;
+__private_extern__ char *_emacs_UP = NULL;
+#define BC _emacs_BC
+#define UP _emacs_UP
+#else
+ char *BC;
+ char *UP;
+#endif
static char tgoto_buf[50];
@@ -125,7 +131,7 @@
args[1] = hpos;
return tparam1 (cm, tgoto_buf, 50, UP, BC, args);
}
-#endif
+
static char *
tparam1 (string, outstring, len, up, left, argp)
diff -aur -x info emacs-21.1.org/src/unexmacosx.c emacs-21.1/src/unexmacosx.c
--- emacs-21.1.org/src/unexmacosx.c Thu Jan 3 12:57:38 2002
+++ emacs-21.1/src/unexmacosx.c Thu Jan 3 10:06:17 2002
@@ -724,7 +724,8 @@
}
else if (strncmp (sectp->sectname, "__la_symbol_ptr", 16) == 0
|| strncmp (sectp->sectname, "__nl_symbol_ptr", 16) == 0
- || strncmp (sectp->sectname, "__dyld", 16) == 0)
+ || strncmp (sectp->sectname, "__dyld", 16) == 0
+ || strncmp (sectp->sectname, "__const", 16) == 0 )
{
if (!unexec_copy (sectp->offset, old_file_offset, sectp->size))
unexec_error ("cannot copy section %s", sectp->sectname);
----- >8 ---------- >8 ----- snip, snip ----- >8 ---------- >8 -----
|
|
From: Immanuel L. <imm...@en...> - 2002-01-11 14:11:00
|
I already mentioned on this list that the do-applescript function crashes emacs if it is given incorrect applescript. I seem to have found the problem! At the end of do_applescript there is a call AEDisposeDesc (&result_desc); This call is executed even if the applescript did not execute correctly, subsequently crashing emacs. Shouldn't this only be executed when the applescript executed correctly? I am also working on a codewarrior-emacs interface through the CW scripting interface. If anyone is interested in the alpha quality code they can contact me Immanuel *************************************************************************** A day for firm decisions!!!!! Or is it? Immanuel Litzroth Software Development Engineer Enfocus Software Kleindokkaai 3-5 B-9000 Gent Belgium Voice: +32 9 269 23 90 Fax : +32 9 269 16 91 Email: Imm...@en... web : www.enfocus.be *************************************************************************** |
|
From: Andrew C. <ak...@cs...> - 2002-01-05 08:22:42
|
> [...] Anyway, I have it basically working (I haven't tested > everything yet) w/ EMACS_INT == long long (I got distracted by > thinking that cw6 vs os x was my fault somehow). > > Anyway, is this something that we're interested in given that it > shouldn't be a problem on os x? Hi Peter, That's great news! The removal of the 256MB limitation would be very nice indeed. If it is not a lot of code, please post it. Otherwise post it anyway but I need to ask you to assign the copyright to FSF (by sending a signed document to them) so we can incorporate it into the main source tree. The reason for this, if you don't know already, is explained here: http://www.gnu.org/copyleft/gpl-faq.html#AssignCopyright Andrew. |
|
From: d p c. <dp...@qu...> - 2002-01-03 19:07:05
|
Hmmm... i tried to send this last night, but didn't see anything. Anyway, I have it basically working (I haven't tested everything yet) w/ EMACS_INT == long long (I got distracted by thinking that cw6 vs os x was my fault somehow). Anyway, is this something that we're interested in given that it shouldn't be a problem on os x? \p --- It will yet be the proud boast of women that they never contributed a line to the Bible. --- George W. Foote |
|
From: Andrew C. <ak...@cs...> - 2002-01-03 08:20:15
|
Hi Everyone,
I posted a bug fix to the patch emacs-21.1-2-mac.patch.gz that was
supposed to improve the speed of redisplay. Turns out it didn't
really do anything (it didn't do any harm either). My apologies.
Here is one that really works! This fix makes a big difference for
people using a quail input method for typing Chinese or Japanese.
Without it, input is very sluggish because there's a long delay (to
regenerate and reinstall the menus) after each key press. It may fix
other input-related sluggishness too. You'd never know :-).
Please apply the following patch to src/macmenu.c (without applying
the previous one; undo it if you have already applied that one).
Andrew.
-----
--- macmenu.c.orig Fri Nov 2 10:50:08 2001
+++ macmenu.c Thu Jan 3 15:48:06 2002
@@ -1336,11 +1336,13 @@
= (Lisp_Object *) alloca (previous_menu_items_used
* sizeof (Lisp_Object));
+#if 0
/* If we are making a new widget, its contents are empty,
do always reinitialize them. */
if (! menubar_widget)
previous_menu_items_used = 0;
-
+#endif
+
buffer = XWINDOW (FRAME_SELECTED_WINDOW (f))->buffer;
specbind (Qinhibit_quit, Qt);
/* Don't let the debugger step into this code
@@ -1370,12 +1372,13 @@
inhibit_garbage_collection ();
/* Save the frame's previous menu bar contents data. */
- bcopy (XVECTOR (f->menu_bar_vector)->contents, previous_items,
- previous_menu_items_used * sizeof (Lisp_Object));
+ if (previous_menu_items_used)
+ bcopy (XVECTOR (f->menu_bar_vector)->contents, previous_items,
+ previous_menu_items_used * sizeof (Lisp_Object));
/* Fill in the current menu bar contents. */
menu_items = f->menu_bar_vector;
- menu_items_allocated = XVECTOR (menu_items)->size;
+ menu_items_allocated = VECTORP (menu_items) ? ASIZE (menu_items) : 0;
init_menu_items ();
for (i = 0; i < XVECTOR (items)->size; i += 4)
{
@@ -1407,9 +1410,10 @@
of the menu bar, skip redisplaying it. Just exit. */
for (i = 0; i < previous_menu_items_used; i++)
- if (menu_items_used == i
- || (!EQ (previous_items[i], XVECTOR (menu_items)->contents[i])))
- break;
+ if (menu_items_used == i
+ || (!Fequal (previous_items[i],
+ XVECTOR (menu_items)->contents[i])))
+ break;
if (i == menu_items_used && i == previous_menu_items_used && i != 0)
{
free_menubar_widget_value_tree (first_wv);
|
|
From: Andrew C. <ak...@cs...> - 2002-01-03 03:13:53
|
> Is it possible to build a emacs 21.1 for OSX which both works under > Cocoa and X Window?... > > Thanks in advance, > > PS: I gave it a try, but the compilation fails. Hi Felix, Because Emacs is written to run under a single type of window system determined and fixed at configuration time, it will require quite a bit of modification to the code to create a single binary that supports two types of window systems. The current code uses the Carbon API and not Cocoa nor X Window. It should not be hard to compile Emacs to run under X Window on the Mac. It should be just a matter of fixing the autoconf file and perhaps dealing with a few bugs. Someone was working on this a while ago but I haven't heard from that effort again. I do not run X Window on my Mac so perhaps someone else would be kind enough to try this. Andrew. |
|
From: Francois F. I. <fe...@in...> - 2001-12-27 10:08:56
|
Is it possible to build a emacs 21.1 for OSX which both works under Cocoa and X Window?... Thanks in advance, PS: I gave it a try, but the compilation fails. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Si on avait su que tout ca finirait pour voir Barthez embrasser McDonald's." Professional: http://www.laas.fr/~felix Jean Luc Godard Personal: http://www.ingrand.net/felix |
|
From: Andrew C. <ak...@cs...> - 2001-12-14 07:27:00
|
Hi Everyone,
This change improves the patch emacs-21.1-2-mac.patch.gz for building
Emacs 21.1 on Mac OS X.
Without it, the entire menu tree is rebuilt every time a frame is
redisplayed. This is unnecessary since Emacs rebuilds the menu tree
when the menu bar is clicked anyway.
This (performance) bug does not cause anything to be displayed
incorrectly (afterall it is doing more than that is necessary).
However it causes input to be very sluggish when each key-press
requires a redisplay, e.g., when one is using a quail input method for
typing Chinese or Japanese.
Please apply the following patch to src/macmenu.c.
Andrew.
-----
--- emacs-21.1.30/src/macmenu.c Sat Oct 27 10:28:58 2001
+++ emacs/src/macmenu.c Fri Dec 14 14:33:12 2001
@@ -1318,6 +1318,11 @@
XSETFRAME (Vmenu_updating_frame, f);
+ if (! menubar_widget)
+ deep_p = 1;
+ else if (pending_menu_activation && !deep_p)
+ deep_p = 1;
+
wv = xmalloc_widget_value ();
wv->name = "menubar";
wv->value = 0;
@@ -1325,116 +1330,155 @@
wv->button_type = BUTTON_TYPE_NONE;
first_wv = wv;
- {
- /* Make a widget-value tree representing the entire menu trees. */
-
- struct buffer *prev = current_buffer;
- Lisp_Object buffer;
- int specpdl_count = specpdl_ptr - specpdl;
- int previous_menu_items_used = f->menu_bar_items_used;
- Lisp_Object *previous_items
- = (Lisp_Object *) alloca (previous_menu_items_used
- * sizeof (Lisp_Object));
-
- /* If we are making a new widget, its contents are empty,
- do always reinitialize them. */
- if (! menubar_widget)
- previous_menu_items_used = 0;
-
- buffer = XWINDOW (FRAME_SELECTED_WINDOW (f))->buffer;
- specbind (Qinhibit_quit, Qt);
- /* Don't let the debugger step into this code
- because it is not reentrant. */
- specbind (Qdebug_on_next_call, Qnil);
-
- record_unwind_protect (Fset_match_data, Fmatch_data (Qnil, Qnil));
- if (NILP (Voverriding_local_map_menu_flag))
- {
- specbind (Qoverriding_terminal_local_map, Qnil);
- specbind (Qoverriding_local_map, Qnil);
- }
-
- set_buffer_internal_1 (XBUFFER (buffer));
-
- /* Run the Lucid hook. */
- call1 (Vrun_hooks, Qactivate_menubar_hook);
- /* If it has changed current-menubar from previous value,
- really recompute the menubar from the value. */
- if (! NILP (Vlucid_menu_bar_dirty_flag))
- call0 (Qrecompute_lucid_menubar);
- safe_run_hooks (Qmenu_bar_update_hook);
- FRAME_MENU_BAR_ITEMS (f) = menu_bar_items (FRAME_MENU_BAR_ITEMS (f));
-
- items = FRAME_MENU_BAR_ITEMS (f);
-
- inhibit_garbage_collection ();
-
- /* Save the frame's previous menu bar contents data. */
- bcopy (XVECTOR (f->menu_bar_vector)->contents, previous_items,
- previous_menu_items_used * sizeof (Lisp_Object));
-
- /* Fill in the current menu bar contents. */
- menu_items = f->menu_bar_vector;
- menu_items_allocated = XVECTOR (menu_items)->size;
- init_menu_items ();
- for (i = 0; i < XVECTOR (items)->size; i += 4)
- {
- Lisp_Object key, string, maps;
-
- key = XVECTOR (items)->contents[i];
- string = XVECTOR (items)->contents[i + 1];
- maps = XVECTOR (items)->contents[i + 2];
- if (NILP (string))
- break;
-
- wv = single_submenu (key, string, maps);
- if (prev_wv)
- prev_wv->next = wv;
- else
- first_wv->contents = wv;
- /* Don't set wv->name here; GC during the loop might relocate it. */
- wv->enabled = 1;
- wv->button_type = BUTTON_TYPE_NONE;
- prev_wv = wv;
- }
-
- finish_menu_items ();
-
- set_buffer_internal_1 (prev);
- unbind_to (specpdl_count, Qnil);
-
- /* If there has been no change in the Lisp-level contents
- of the menu bar, skip redisplaying it. Just exit. */
-
- for (i = 0; i < previous_menu_items_used; i++)
- if (menu_items_used == i
- || (!EQ (previous_items[i], XVECTOR (menu_items)->contents[i])))
- break;
- if (i == menu_items_used && i == previous_menu_items_used && i != 0)
- {
- free_menubar_widget_value_tree (first_wv);
- menu_items = Qnil;
-
- return;
- }
-
- /* Now GC cannot happen during the lifetime of the widget_value,
- so it's safe to store data from a Lisp_String. */
- wv = first_wv->contents;
- for (i = 0; i < XVECTOR (items)->size; i += 4)
- {
- Lisp_Object string;
- string = XVECTOR (items)->contents[i + 1];
- if (NILP (string))
+ if (deep_p)
+ {
+ /* Make a widget-value tree representing the entire menu trees. */
+
+ struct buffer *prev = current_buffer;
+ Lisp_Object buffer;
+ int specpdl_count = specpdl_ptr - specpdl;
+ int previous_menu_items_used = f->menu_bar_items_used;
+ Lisp_Object *previous_items
+ = (Lisp_Object *) alloca (previous_menu_items_used
+ * sizeof (Lisp_Object));
+
+ /* If we are making a new widget, its contents are empty,
+ do always reinitialize them. */
+ if (! menubar_widget)
+ previous_menu_items_used = 0;
+
+ buffer = XWINDOW (FRAME_SELECTED_WINDOW (f))->buffer;
+ specbind (Qinhibit_quit, Qt);
+ /* Don't let the debugger step into this code
+ because it is not reentrant. */
+ specbind (Qdebug_on_next_call, Qnil);
+
+ record_unwind_protect (Fset_match_data, Fmatch_data (Qnil, Qnil));
+ if (NILP (Voverriding_local_map_menu_flag))
+ {
+ specbind (Qoverriding_terminal_local_map, Qnil);
+ specbind (Qoverriding_local_map, Qnil);
+ }
+
+ set_buffer_internal_1 (XBUFFER (buffer));
+
+ /* Run the Lucid hook. */
+ call1 (Vrun_hooks, Qactivate_menubar_hook);
+ /* If it has changed current-menubar from previous value,
+ really recompute the menubar from the value. */
+ if (! NILP (Vlucid_menu_bar_dirty_flag))
+ call0 (Qrecompute_lucid_menubar);
+ safe_run_hooks (Qmenu_bar_update_hook);
+ FRAME_MENU_BAR_ITEMS (f) = menu_bar_items (FRAME_MENU_BAR_ITEMS (f));
+
+ items = FRAME_MENU_BAR_ITEMS (f);
+
+ inhibit_garbage_collection ();
+
+ /* Save the frame's previous menu bar contents data. */
+ if (previous_menu_items_used)
+ bcopy (XVECTOR (f->menu_bar_vector)->contents, previous_items,
+ previous_menu_items_used * sizeof (Lisp_Object));
+
+ /* Fill in the current menu bar contents. */
+ menu_items = f->menu_bar_vector;
+ menu_items_allocated = VECTORP (menu_items) ? ASIZE (menu_items) : 0;
+ init_menu_items ();
+ for (i = 0; i < XVECTOR (items)->size; i += 4)
+ {
+ Lisp_Object key, string, maps;
+
+ key = XVECTOR (items)->contents[i];
+ string = XVECTOR (items)->contents[i + 1];
+ maps = XVECTOR (items)->contents[i + 2];
+ if (NILP (string))
+ break;
+
+ wv = single_submenu (key, string, maps);
+ if (prev_wv)
+ prev_wv->next = wv;
+ else
+ first_wv->contents = wv;
+ /* Don't set wv->name here; GC during the loop might relocate it. */
+ wv->enabled = 1;
+ wv->button_type = BUTTON_TYPE_NONE;
+ prev_wv = wv;
+ }
+
+ finish_menu_items ();
+
+ set_buffer_internal_1 (prev);
+ unbind_to (specpdl_count, Qnil);
+
+ /* If there has been no change in the Lisp-level contents
+ of the menu bar, skip redisplaying it. Just exit. */
+
+ for (i = 0; i < previous_menu_items_used; i++)
+ if (menu_items_used == i
+ || (!EQ (previous_items[i], XVECTOR (menu_items)->contents[i])))
break;
- wv->name = (char *) XSTRING (string)->data;
- wv = wv->next;
- }
-
- f->menu_bar_vector = menu_items;
- f->menu_bar_items_used = menu_items_used;
- menu_items = Qnil;
- }
+ if (i == menu_items_used && i == previous_menu_items_used && i != 0)
+ {
+ free_menubar_widget_value_tree (first_wv);
+ menu_items = Qnil;
+
+ return;
+ }
+
+ /* Now GC cannot happen during the lifetime of the widget_value,
+ so it's safe to store data from a Lisp_String. */
+ wv = first_wv->contents;
+ for (i = 0; i < XVECTOR (items)->size; i += 4)
+ {
+ Lisp_Object string;
+ string = XVECTOR (items)->contents[i + 1];
+ if (NILP (string))
+ break;
+ wv->name = (char *) XSTRING (string)->data;
+ wv = wv->next;
+ }
+
+ f->menu_bar_vector = menu_items;
+ f->menu_bar_items_used = menu_items_used;
+ menu_items = Qnil;
+ }
+ else
+ {
+ /* Make a widget-value tree containing
+ just the top level menu bar strings. */
+
+ items = FRAME_MENU_BAR_ITEMS (f);
+ for (i = 0; i < XVECTOR (items)->size; i += 4)
+ {
+ Lisp_Object string;
+
+ string = XVECTOR (items)->contents[i + 1];
+ if (NILP (string))
+ break;
+
+ wv = xmalloc_widget_value ();
+ wv->name = (char *) XSTRING (string)->data;
+ wv->value = 0;
+ wv->enabled = 1;
+ wv->button_type = BUTTON_TYPE_NONE;
+ /* This prevents lwlib from assuming this
+ menu item is really supposed to be empty. */
+ /* The EMACS_INT cast avoids a warning.
+ This value just has to be different from small integers. */
+ wv->call_data = (void *) (EMACS_INT) (-1);
+
+ if (prev_wv)
+ prev_wv->next = wv;
+ else
+ first_wv->contents = wv;
+ prev_wv = wv;
+ }
+
+ /* Forget what we thought we knew about what is in the
+ detailed contents of the menu bar menus.
+ Changing the top level always destroys the contents. */
+ f->menu_bar_items_used = 0;
+ }
/* Create or update the menu bar widget. */
|
|
From: Andrew C. <ak...@cs...> - 2001-12-12 05:26:08
|
> I reported yesterday that your process patch has killed gnuclient. I > recompiled using unix domain sockets and now it is working again. I > wonder if it is a good idea to add binaries for this to your site > and/or add some utility elisp scripts (I also have ps-print working > nicely) somewhat like the GNU Emacs on win32 site. Hi Immanuel, Then I will not investigate any further into problems with subprocesses for the time being. I would like to avoid the work of distributing binaries at this time. If anyone like to do so, they're welcome to. I have ownership of the mac/emacs directory at ftp.gnu.org so at the proper time, I can distribute binaries there. But obviously that's only for releases. If patches are small, please post them. For big files, please write and let's discuss where best to distribute them. I'm thinking about gradually moving development support from SourceForge to GNU servers and starting to use the gnu.emacs.* newsgroups. This seems more appropriate to me now that savannah.gnu.org is available and the Mac ports are part of the standard Emacs distribution (I'll be adding the Mac OS X code to the CVS repository). If it becomes necessary, we can create a project for the Mac OS X build of Emacs on Savannah. I'll of course make the proper announcments on these lists when I'm ready to do this. Andrew. |
|
From: Immanuel L. <imm...@en...> - 2001-12-11 12:19:19
|
>>>>> "Andrew" == Andrew Choi <ak...@cs...> writes: Andrew, I reported yesterday that your process patch has killed gnuclient. I recompiled using unix domain sockets and now it is working again. I wonder if it is a good idea to add binaries for this to your site and/or add some utility elisp scripts (I also have ps-print working nicely) somewhat like the GNU Emacs on win32 site. Immanuel *************************************************************************** A day for firm decisions!!!!! Or is it? Immanuel Litzroth Software Development Engineer Enfocus Software Kleindokkaai 3-5 B-9000 Gent Belgium Voice: +32 9 269 23 90 Fax : +32 9 269 16 91 Email: Imm...@en... web : www.enfocus.be *************************************************************************** |
|
From: Andrew C. <ak...@cs...> - 2001-12-08 08:01:46
|
Hi Everyone,
With the patch emacs-21.1-2-mac.patch.gz for building Emacs 21.1 on
Mac OS X, you should be experiencing the following problem. When the
mouse is moved off any text with a mouse face (highlight property),
the highlight is not cleared automatically. This problem can be seen
when you use M-x customize or M-x list-faces-display.
Please try the following patch for the file src/macterm.c.
Andrew.
-----
--- emacs-21.1.30/src/macterm.c Tue Oct 30 21:16:48 2001
+++ emacs/src/macterm.c Sat Dec 8 15:47:25 2001
@@ -7676,8 +7676,11 @@
clear_mouse_face (dpyinfo)
struct mac_display_info *dpyinfo;
{
+#if 0 /* This prevents redrawing tool bar items when changing from one
+ to another while a tooltip is open, so don't do it. */
if (tip_frame)
return;
+#endif
if (! NILP (dpyinfo->mouse_face_window))
show_mouse_face (dpyinfo, DRAW_NORMAL_TEXT);
|
|
From: Andrew C. <ak...@cs...> - 2001-12-08 07:55:12
|
Hi Everyone!
With the patch emacs-21.1-2-mac.patch.gz for building Emacs 21.1 on
Mac OS X, you should be experiencing problems with subprocesses not
completely returning all their output.
Please try the following patches for the files src/process.c and
src/s/darwin.h.
Andrew.
-----
--- emacs-21.1/src/process.c Tue Sep 25 16:21:22 2001
+++ emacs/src/process.c Tue Dec 4 09:03:31 2001
@@ -2512,6 +2512,14 @@
if (update_tick != process_tick && do_display)
{
Atemp = input_wait_mask;
+#ifdef MAC_OSX
+ /* On Mac OS X, the SELECT system call always says input is
+ present (for reading) at stdin, even when none is. This
+ causes the the call to SELECT below to return 1 and
+ status_notify not to be called. As a result output of
+ subprocesses are incorrectly discarded. */
+ FD_CLR (0, &Atemp);
+#endif
EMACS_SET_SECS_USECS (timeout, 0, 0);
if ((select (max (max_process_desc, max_keyboard_desc) + 1,
&Atemp, (SELECT_TYPE *)0, (SELECT_TYPE *)0,
--- emacs-21.1.30/src/s/darwin.h Sat Jun 30 23:21:19 2001
+++ emacs/src/s/darwin.h Wed Dec 5 12:06:47 2001
@@ -76,7 +76,7 @@
to read the input and send it to the true Emacs process
through a pipe. */
-#define INTERRUPT_INPUT 1
+#define INTERRUPT_INPUT
/* Letter to use in finding device name of first pty,
if system supports pty's. 'a' means it is /dev/ptya0 */
@@ -103,7 +103,7 @@
* Define HAVE_PTYS if the system supports pty devices.
*/
-#define HAVE_PTYS
+/* #define HAVE_PTYS */
/*
* Define NONSYSTEM_DIR_LIBRARY to make Emacs emulate
|
|
From: Andrew C. <ak...@cs...> - 2001-12-06 08:55:44
|
> I have to things I would like to change: > > 1) the mac-file-name-to-posix and posix-file-name-to-mac don't seem to > be aware of volumes and mounting > (posix-file-name-to-mac "/Users/immanuel/workspace") > -> "Users:immanuel:workspace" and should be > 'Macintosh HD:Users:immanuel:workspace" > (mac-file-name-to-posix "Macintosh HD:Users:immanuel:workspace") > -> "/Macintosh HD/Users/immanuel/workspace" and should be > "/Users/immanuel/workspace > I have some code that does this, and I could send you a patch this > weekend that does this. Do you have any problems with this? Thanks. That will be very nice. > 2) I would like to have emacs be aware of apple events, so that I can > use it as an extension editor for codewarrior. I will not have time > to program this for another two weeks, but would you consider > adding this to emacs? I am currently trying to get C-g to work correctly, which I consider important. There are a few other things I'd like to work on after that so I probably won't get to Apple Events any time soon. Please feel free to work on them. Andrew. |
|
From: Immanuel L. <imm...@en...> - 2001-11-23 10:35:46
|
On MacOSX I see the following in the src/mac.c file #if 0 defsubr (&Sx_selection_exists_p); #endif /* 0 */ I have had problems with this. Emacs needs this function in menubar.el and I cannot redefine without having emacs hang. Is there any reason why this is commented out? I also have problems setting debug-on-error to true. It also hangs emacs. Immanuel *************************************************************************** A day for firm decisions!!!!! Or is it? Immanuel Litzroth Software Development Engineer Enfocus Software Kleindokkaai 3-5 B-9000 Gent Belgium Voice: +32 9 269 23 90 Fax : +32 9 269 16 91 Email: Imm...@en... web : www.enfocus.be *************************************************************************** |
|
From: Andrew C. <ak...@cs...> - 2001-11-06 16:20:41
|
Thanks Peter. A little while ago, Tsutomu Ikegami sent in a set of patches that includes that one. Sorry for not making the connection that the problem has already been solved. Therefore, there is no need to worry about reporting it. It is already in the pipeline for patches to be committed. Andrew. |
|
From: Dan S. <seg...@ma...> - 2001-11-06 14:35:57
|
Hi, > The problem is taht editfns.c doesn't include <stdio.h>. Since > there is no prototype the code generated moves the double into > fp1 rather than onto the stack for varadic functions. If I > include <stdio.h> then the right code gets generated and things > seem to work ok. Argh! I must be getting old. :-/ Fifteen or twenty years ago, the first place I would have looked was the disassembly listing. [ editing, compiling, linking, testing ] That did it. I'm surprised that no one has found this before. Surely other architectures (Sparc? Alpha? HP PA?) must have this property. OTOH, I bet that gcc handles sprintf as a special case on those boxen anyway. "It works This Way, why should I do it the Right Way?" :-/ Thanks, \p. What's the best way to get this fix merged in? Shall I send it to bug...@gn...? Dan -- Dan Sommers, Esq., Ltd., The Third mailto:seg...@ma... |
|
From: d p c. <we...@cs...> - 2001-11-06 08:47:12
|
The problem is taht editfns.c doesn't include <stdio.h>. Since there is no prototype the code generated moves the double into fp1 rather than onto the stack for varadic functions. If I include <stdio.h> then the right code gets generated and things seem to work ok. \p -- Far more crucial than what we know or do not know is what we do not want to know. -- Eric Hoffer |
|
From: Dan S. <seg...@ma...> - 2001-11-02 17:43:19
|
There is a very strange bug lurking somewhere in the Mac Emacs 21
code. I exchanged some private email with Andrew Choi (thanks
again, Andrew!), and at least we're both getting the same results.
At 19:29 -0600 2001-10-30, Dan Sommers wrote:
> Copied and pasted from my *scratch* buffer:
>
> (format "%f" 1.0) ; "%f" loses
> "0.000000"
> (format "%s" 1.0) ; "%s" wins
> "1.0"
>
> I traced this one all the way down to the call to sprintf on
> line 3416 of editfns.c, and everything looks good except
> sprintf's output. it happens with or without my .emacs file,
> and with various compiler optimization and PPC processor
> settings. I'm using CodeWarrior 5.3 and [the] pre-packaged
> project, and Mac OS 9.0.4, if that makes any difference. I'll
> give it a shot later with MPW, as soon as I finish downloading
> it (at 56K...).
>
> I think this bug also existed in Mac Emacs 20.6. I tracked it
> down because of strange output from ps-print (*everything* was
> black, including the background), and I had that same symptom
> in 20.6.
[ Aside: ps-print loses because it depends on (format "%f ...)
to format RGB values, and if (format "%f" ...) keeps returning
"0.000000," then all those colors are *black*.
As a temporary work-around for this particular problem, I added
this to my .emacs file:
;; Mac Emacs (format "%f" 1.0) loses; these kluges prevent
;; ps-print from losing, too....
(setq ps-color-format " %s %s %s "
ps-float-format " %s ")
End of aside. ]
At 13:58 +0800 2001-11-02, Andrew Choi wrote:
> Thank you for the bug report. I've spent some time on it and I
> must say I'm baffled. I added a simple block
>
> {
> char s[20];
>
> sprintf(s, "%f", 1.0);
> }
>
> at the beginning of main() and that works correctly. I also
> added this block right after the sprintf line in questions (in
> Fformat() in editfns.c) and it didn't work. I also tried
> `(format "%f" 1.0)' in the MPW version and that gives a
> "0.000000" also. Perhaps I can post this to mac-emacs-devel and
> see if other people have some ideas.
I had tried these things in the mean time, too, and got the same
results, and that's where we are.
Any ideas?
Thanks,
Dan
--
Dan Sommers, Esq., Ltd., The Third
mailto:seg...@ma...
|
|
From: Andrew C. <ak...@cs...> - 2001-11-02 03:29:03
|
The following message is a courtesy copy of an article that has been posted to comp.emacs as well. Here is a patch to Emacs 21.1 to allow it to build and run under Mac OS X: http://www.cse.cuhk.edu.hk/~akochoi/emacs/macosx/emacs-21.1-2-mac.patch.gz The instructions for applying it are contained in the file: http://www.cse.cuhk.edu.hk/~akochoi/emacs/macosx/readme.txt The GUI code is basically a Carbonized version of that in Emacs 21 for Mac OS classic. The Unix API of Mac OS X is used to implement synchronous and asychronous subprocess support and networking support. A new `unexec' for the Mach-O executable file format, written entirely from scratch (src/unexmacosx.c), provides support for `dump-emacs'. The autoconf/makefile mechanism is adopted so Emacs will built on Mac OS X with the Developer Tools installed. Note that although Emacs 21 is released software, this patch is alpha software. Please treat it as such. I will continue to work on it though. Comments and contributions (code) are welcome! I will work on adding this patch to the CVS repository for the next release. Have fun with it! Andrew Choi (ak...@ma...). |
|
From: Andrew C. <ak...@cs...> - 2001-10-31 00:39:33
|
d p chang <dp...@qu...> writes: > Andrew Choi <ak...@cs...> writes: > > > However, many things cause events to be generated in X, which can > > simply be picked up by the main event loop and handled. The Carbon > > active scroll bars use callback functions to perform the scrolling. > > It's not so easy to adapt this model (Carbon) to one with an event > > loop that expect to receive active scrolling events (Emacs). > > is this what you mean by poll? the initial callback continues to call > the emacs code w/ a 'mouse down' until it moved out of the control > (for the arrow control things) or 'mouse up'. IIRC, one can't call Emacs code within a Mac Toolbox callback function. I can't explain the exact reason very well. But see the comments at the being of xdisp.c. Mouse events are handled in XTread_socket in macterm.c by keeping track of whether the mouse is down or up, checking the position of the mouse every time through the function, and generating the appropriate event to pass back to Emacs in the input_event buffer. That's input by `polling' instead of `event-driven', right? > > Some events are even absent. > > What are these? (if you can remember off the top of your head). Just > grepping though the source hasn't made these obvious Two types that I can think of that would be nice to have are mouse movement (in general) and movement of scroll bar control handles. Andrew. |
|
From: d p c. <dp...@qu...> - 2001-10-30 21:56:10
|
Andrew Choi <ak...@cs...> writes: > However, many things cause events to be generated in X, which can > simply be picked up by the main event loop and handled. The Carbon > active scroll bars use callback functions to perform the scrolling. > It's not so easy to adapt this model (Carbon) to one with an event > loop that expect to receive active scrolling events (Emacs). is this what you mean by poll? the initial callback continues to call the emacs code w/ a 'mouse down' until it moved out of the control (for the arrow control things) or 'mouse up'. > Some events are even absent. What are these? (if you can remember off the top of your head). Just grepping though the source hasn't made these obvious \p --- No race can prosper till it learns there is as much dignity in tilling a field as in writing a poem --- Booker T. Washington |
|
From: Andrew C. <ak...@cs...> - 2001-10-30 07:23:06
|
d p chang <we...@cs...> writes: > > For example, it will take a bit more work to make scroll-bars > > behave like standard (Mac) ones. Currently, scrolling will not > > > `auto-repeat' if one clicks and holds down the mouse in the up or > > down arrow area. > > This is interesting. I forget how x controls do this, do they do the > autorepeat themselves since they have a similar problem. I must admit I need to go back to check the reference books and the code to answer accurately. However, many things cause events to be generated in X, which can simply be picked up by the main event loop and handled. The Carbon active scroll bars use callback functions to perform the scrolling. It's not so easy to adapt this model (Carbon) to one with an event loop that expect to receive active scrolling events (Emacs). Some events are even absent. Right now the Mac code detects mouse movement by polling. There has to be a better way to this. These are the kind of improvements to the event handling code that I am thinking about. Andrew. |
|
From: d p c. <we...@cs...> - 2001-10-30 04:08:13
|
At 11.00 +0800 2001.10.30, Andrew Choi wrote: >d p chang <dp...@qu...> writes: > >> However, the carbon model looks a lot like the x (windows too) model >> so it should be more natural? I guess it would be more painful to >> support classic and osx w/o ifdef-ing. > >Subtle differences can make porting difficult. oh so true. >For example, it will >take a bit more work to make scroll-bars behave like standard (Mac) >ones. Currently, scrolling will not `auto-repeat' if one clicks and >holds down the mouse in the up or down arrow area. This is interesting. I forget how x controls do this, do they do the autorepeat themselves since they have a similar problem. \p -- Far more crucial than what we know or do not know is what we do not want to know. -- Eric Hoffer |
|
From: Andrew C. <ak...@cs...> - 2001-10-30 03:00:45
|
d p chang <dp...@qu...> writes: > However, the carbon model looks a lot like the x (windows too) model > so it should be more natural? I guess it would be more painful to > support classic and osx w/o ifdef-ing. Subtle differences can make porting difficult. For example, it will take a bit more work to make scroll-bars behave like standard (Mac) ones. Currently, scrolling will not `auto-repeat' if one clicks and holds down the mouse in the up or down arrow area. At some point (in transition to the Mac OS X code) I had a Carbonized verison that will run on Classic (with CarbonLib, of course). Right now the Mac OS X code contains a lot of ifdef's. Perhaps if it is worth the effort, at some point we can move towards a unified Carbonized version. > I don't see the connection between signals and events (other than > signalling from within an event callback). Oh, I was thinking about how to get Emacs to do interrupt-driven input via signals. Specifically I was thinking about how to `connect' keyboard and mouse events to (Unix) signal handling in Emacs. Andrew. |
|
From: d p c. <dp...@qu...> - 2001-10-30 02:00:03
|
Since i'm still reading up on carbon things you should correct my misunderstandings here... Andrew Choi <ak...@cs...> writes: > d p chang <dp...@qu...> writes: > >>> Once it is less buggy, what I want to do next is perhaps image >>> support and better event handling. >> >> I'm not sure what you mean by the later? (I've only used the unix >> and normal macos versions where event handling seems fine). Is this >> a carbon thing? > > But there is an important area where the implementation can be > improved. Emacs basically uses X Windows's model of event handling. > However, in the current Mac ports, input events are obtained by > polling and passed through XTread_socket (mac_read_socket in 20.6). However, the carbon model looks a lot like the x (windows too) model so it should be more natural? I guess it would be more painful to support classic and osx w/o ifdef-ing. > Also I haven't figured out the relationship between (Unix) signals > and event handling in a Carbon application. So there is really no > signal handling in the Mac OS X port. E.g., it doesn't handle C-g > at all. It is quite important to get that to work, at least. I don't see the connection between signals and events (other than signalling from within an event callback). \p --- Luck is when preparation meets opportunity. --- Elmer Letterman |
