mac-emacs-devel Mailing List for Emacs for Mac OS 8/9
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: <d.v...@at...> - 2003-04-24 18:06:41
|
Hi, It is very silent here. Does anyone else has a problem with the latest snapshot ru... I have MakeNewCWindow returning NULL and would like to kno... already available before going into debigging. Regards, Daniel |
|
From: d p c. <we...@me...> - 2002-10-19 19:01:02
|
there is a missing entry in this list found in the generated
site-lisp/font.el for mac. if you use the default entry
(mac . (x-font-create-name x-font-create-object))
basic stuff in w3 appears to work ok
\p
---
I haven't committed a crime. What I did was fail to comply with the
law. --- David Dinkins
|
|
From: Andrew C. <ak...@sh...> - 2002-08-25 17:24:31
|
> [...] > I saw the same error on "./configure --without-carbon --with-x > --x-lib=/usr/X11R6/libstatic; make". > > mac.o is not be linked when configured --without-carbon (see > Makefile.in:540) > > I think we need not init_mac_osx_environment() nor sys_select() > on non-carbon environemnt. Am I right? > > How about this patch? > > --- patch begin --- > Index: src/emacs.c > =================================================================== > RCS file: /cvsroot/emacs/emacs/src/emacs.c,v > retrieving revision 1.314 > diff -u -r1.314 emacs.c > --- src/emacs.c 24 Aug 2002 03:15:22 -0000 1.314 > +++ src/emacs.c 25 Aug 2002 05:44:28 -0000 > @@ -1363,9 +1363,11 @@ > init_ntproc (); /* must precede init_editfns. */ > #endif > > +#ifdef HAVE_CARBON > #ifdef MAC_OSX > if (initialized) > init_mac_osx_environment (); > +#endif > #endif > > /* egetenv is a pretty low-level facility, which may get called in > Index: src/s/darwin.h > =================================================================== > RCS file: /cvsroot/emacs/emacs/src/s/darwin.h,v > retrieving revision 1.5 > diff -u -r1.5 darwin.h > --- src/s/darwin.h 11 Aug 2002 00:26:24 -0000 1.5 > +++ src/s/darwin.h 25 Aug 2002 05:44:28 -0000 > @@ -309,9 +309,11 @@ > #define free unexec_free > #endif > > +#ifdef HAVE_CARBON > /* Reroute calls to SELECT to the version defined in mac.c to fix the > problem of Emacs requiring an extra return to be typed to start > working when started from the command line. */ > #if defined (emacs) || defined (temacs) > #define select sys_select > +#endif > #endif > --- patch end --- Hi Nozomu, Thank you for the patch. Calling init_mac_osx_environment allows Emacs support files (like Lisp files) to be put inside the application bundle. But since there is no where to put the code when compiling for X Window, this is a quick fix. But X Window versions will not have this capability. I've just checked this change into the CVS repository. Andrew |
|
From: Nozomu A. <na...@ma...> - 2002-08-25 06:17:26
|
Hi,
>> Hi,
>>
>> I'm trying to compile emacs on my OS X system, and even though I
>> follow
>> all the steps from the description, I get the following error:
>>
>> /usr/bin/ld: warning prebinding disabled because of undefined symbols
>> /usr/bin/ld: Undefined symbols:
>> _init_mac_osx_environment
>> _sys_select
>> make[1]: *** [temacs] Error 1
>> make: *** [bootstrap-src] Error 2
>>
>> Does anyone here know what this means?
>>
>> Cheers,
>> David.
I saw the same error on "./configure --without-carbon --with-x
--x-lib=/usr/X11R6/libstatic; make".
mac.o is not be linked when configured --without-carbon (see
Makefile.in:540)
I think we need not init_mac_osx_environment() nor sys_select()
on non-carbon environemnt. Am I right?
How about this patch?
--- patch begin ---
Index: src/emacs.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/emacs.c,v
retrieving revision 1.314
diff -u -r1.314 emacs.c
--- src/emacs.c 24 Aug 2002 03:15:22 -0000 1.314
+++ src/emacs.c 25 Aug 2002 05:44:28 -0000
@@ -1363,9 +1363,11 @@
init_ntproc (); /* must precede init_editfns. */
#endif
+#ifdef HAVE_CARBON
#ifdef MAC_OSX
if (initialized)
init_mac_osx_environment ();
+#endif
#endif
/* egetenv is a pretty low-level facility, which may get called in
Index: src/s/darwin.h
===================================================================
RCS file: /cvsroot/emacs/emacs/src/s/darwin.h,v
retrieving revision 1.5
diff -u -r1.5 darwin.h
--- src/s/darwin.h 11 Aug 2002 00:26:24 -0000 1.5
+++ src/s/darwin.h 25 Aug 2002 05:44:28 -0000
@@ -309,9 +309,11 @@
#define free unexec_free
#endif
+#ifdef HAVE_CARBON
/* Reroute calls to SELECT to the version defined in mac.c to fix the
problem of Emacs requiring an extra return to be typed to start
working when started from the command line. */
#if defined (emacs) || defined (temacs)
#define select sys_select
+#endif
#endif
--- patch end ---
Regards,
Nozomu Ando
|
|
From: Andrew C. <ak...@sh...> - 2002-08-23 23:48:34
|
> Hi, > > I'm trying to compile emacs on my OS X system, and even though I follow > all the steps from the description, I get the following error: > > /usr/bin/ld: warning prebinding disabled because of undefined symbols > /usr/bin/ld: Undefined symbols: > _init_mac_osx_environment > _sys_select > make[1]: *** [temacs] Error 1 > make: *** [bootstrap-src] Error 2 > > Does anyone here know what this means? > > Cheers, > David. Hi David, These two functions are defined at the end of the file src/mac.c. This is the latest version in the CVS repository: http://savannah.gnu.org/cgi-bin/viewcvs/emacs/emacs/src/mac.c?rev=1.9&content-type=text/vnd.viewcvs-markup Be sure to check mac.o's modification date and use the command `nm' to check whether it exports these two symbols. Andrew. P.S. This mailing list will not be used soon. Please see the web page http://members.shaw.ca/akochoi-emacs/index.html for where to obtain help on Emacs for Mac OS X in the future. |
|
From: David S. <da...@we...> - 2002-08-23 18:33:27
|
Hi, I'm trying to compile emacs on my OS X system, and even though I follow all the steps from the description, I get the following error: /usr/bin/ld: warning prebinding disabled because of undefined symbols /usr/bin/ld: Undefined symbols: _init_mac_osx_environment _sys_select make[1]: *** [temacs] Error 1 make: *** [bootstrap-src] Error 2 Does anyone here know what this means? Cheers, David. |
|
From: Piet v. O. <pi...@cs...> - 2002-08-22 09:25:00
|
>>>>> Andrew Choi <ak...@sh...> (AC) writes: AC> Hi Everyone, AC> I have just checked in to the CVS a very nice patch contributed by AC> Steven Tamm which lets Emacs recognize 2- and 3-button and wheel mice. AC> Attached below is his description of it, among other things. [...] >> mac-wheel-button-is-mouse-2. If t, causes the mouse-wheel button to map >> to mouse-2 and the "right" mouse button to map to mouse-3. If nil, the >> mapping is reversed. The default is t. Actually, as implemented it works just the opposite way. -- Piet van Oostrum <pi...@cs...> URL: http://www.cs.uu.nl/~piet [PGP] Private email: P.v...@hc... |
|
From: Andrew C. <ak...@sh...> - 2002-08-15 18:03:01
|
Hi! Emacs Users and Developers, I've finally set up a separate web page for Emacs for Mac OS X: http://members.shaw.ca/akochoi-emacs/ I hope to be updating this page quite often (perhaps once or twice a month) with information on new developments on the Mac OS X code. The old webpage at SourceForge http://mac-emacs.sourceforge.net/ has also been updated to carry only information on Emacs for Mac OS 8/9. As you probably know, these two mailing lists, mac-emacs-devel and mac-emacs-users hosted on lists.sourceforge.net, were originally used to discuss Emacs for Mac OS Classic. As the version of Emacs for Mac OS X matures, users and developers have continued to carry out their discussions on this new version there. Since the Mac OS code (both X and classic) is already part of the standard Emacs code, I feel that it is now more suitable to use the common venues already available to Emacs users and developers of other platforms. Many more knowledgeable people there will be available to answer general usage questions. Mac OS users and developers of Emacs will hopefully also feel less isolated and be part of this bigger Emacs community. I would like to keep around the Mac OS 8/9 page at SourceForge, so people can still find my projects, but phase out the mailing lists and discussion forums there. So from now on, to discuss the development of Emacs for Mac OS X and 8/9 or submit patches and bug fixes, please post to the mailing list ema...@gn.... Please post general questions to the gnu.emacs.help newsgroup. Read and post bug reports and fixes in the gnu.emacs.bug newsgroup. To send bug reports from Emacs for Mac OS X, type M-x report-emacs-bug RET. Also please read the comp.emacs newsgroup for general information and announcements about Emacs. As usual please read the posts in the respectively mailing lists and newsgroups to get a feeling of their scopes before you post, as I'm sure you will. Therefore, so long! But see you on the other channels. Yours faithfully, Andrew. |
|
From: Andreas S. <sc...@su...> - 2002-08-12 16:08:39
|
Andrew Choi <ak...@sh...> writes: |> > Andrew Choi <ak...@sh...> writes: |> > |> > |> #!/bin/sh |> > |> /Applications/Emacs.app/Contents/MacOS/Emacs $* |> > |> > Please use "$@" (including the quotes) instead of $* to get quoting right. |> > |> > Andreas. |> |> Hi Andreas, |> |> Would you consider contributing the necessary changes to makefile.in |> for building and installation Emacs on Mac OS X? Not sure which makefile.in you mean. I cannot find anything related to this issue. Andreas. -- Andreas Schwab, SuSE Labs, sc...@su... SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." |
|
From: Andrew C. <ak...@sh...> - 2002-08-12 15:51:43
|
> Andrew Choi <ak...@sh...> writes: > > |> #!/bin/sh > |> /Applications/Emacs.app/Contents/MacOS/Emacs $* > > Please use "$@" (including the quotes) instead of $* to get quoting right. > > Andreas. Hi Andreas, Would you consider contributing the necessary changes to makefile.in for building and installation Emacs on Mac OS X? Andrew. |
|
From: Andreas S. <sc...@su...> - 2002-08-12 08:40:23
|
Andrew Choi <ak...@sh...> writes: |> #!/bin/sh |> /Applications/Emacs.app/Contents/MacOS/Emacs $* Please use "$@" (including the quotes) instead of $* to get quoting right. Andreas. -- Andreas Schwab, SuSE Labs, sc...@su... SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." |
|
From: Andrew C. <ak...@sh...> - 2002-08-12 04:52:54
|
Hi Everyone, I have just checked in Steven Tamm's fix to allow keys to be first passed to the Mac Toolbox for processing before they are seen by Emacs while USE_CARBON_EVENTS is defined. This is important for people using a Mac OS input method, e.g., because command-space is the script switching key and must be seen by the Mac Toolbox. Also control and command key combinations are used to set different options for the input methods. I have also introduced two new variables mac-pass-control-to-system and mac-pass-command-to-system, whose values determine whether keys typed with the control and command keys, respectively, are passed to the Mac Toolbox. They both default to t so the behavior should be identical to the code before USE_CARBON_EVENTS was introduced. Andrew. |
|
From: Steven T. <ste...@ma...> - 2002-08-11 19:38:10
|
Not sure what the problem is here. The code here *always* has the services menu activated as if the clipboard is filled with text, so after starting up the application, it should just work. Can you use the mouse-wheel? If you put an "#error" directive in init_service_handler(), does compilation stop. I haven't compiled with gcc3 yet, but I highly doubt that is it. -Steven On Sunday, August 11, 2002, at 09:58 AM, Marc-Antoine Parent wrote: > Good day! > I just updated Emacs from CVS. I know I am up-to-date and should have > Steven's patch for access to the services menu. > However, my Services menu stays empty. (I also tried filling the > clipboard, selecting text, removing .emacs, etc.) > I am building with gcc version 3.1 20020105 on a 10.1.5 system. > If you have an idea or diagnostic procedure to propose, I'd love to > help debug this. |
|
From: Andrew C. <ak...@sh...> - 2002-08-11 17:16:59
|
> Good day!
> I just updated Emacs from CVS. I know I am up-to-date and should have
> Steven's patch for access to the services menu.
> However, my Services menu stays empty. (I also tried filling the
> clipboard, selecting text, removing .emacs, etc.)
> I am building with gcc version 3.1 20020105 on a 10.1.5 system.
> If you have an idea or diagnostic procedure to propose, I'd love to help
> debug this.
>
> Marc-Antoine Parent
>
> P.S. I sent this before subscribing; the message was described as held.
> Apologies for repost if the message is then released.
> MAP
Hi Marc-Antoine,
Not a problem. I've just deleted that pending post. We had a problem
with spam so I thought it was better to manage the list this way.
Regarding Steven's patch for the Services menu, I'm quite sure I've
checked it in with this patch:
2002-08-03 Andrew Choi <ak...@sh...>
* macterm.c (USE_CARBON_EVENTS): New macro.
[...]
(mac_handle_service_event): New function.
(init_service_handler): New function.
[...]
My `Emacs' menu now has an enabled `Services...' submenu very much
like other applications, but most of the further submenus are
disabled. I don't know how to use them. Perhaps Steven can help.
Andrew.
|
|
From: Marc-Antoine P. <map...@ro...> - 2002-08-11 16:58:51
|
Good day! I just updated Emacs from CVS. I know I am up-to-date and should have Steven's patch for access to the services menu. However, my Services menu stays empty. (I also tried filling the clipboard, selecting text, removing .emacs, etc.) I am building with gcc version 3.1 20020105 on a 10.1.5 system. If you have an idea or diagnostic procedure to propose, I'd love to help debug this. Marc-Antoine Parent P.S. I sent this before subscribing; the message was described as held. Apologies for repost if the message is then released. MAP |
|
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. |
|
From: Andrew C. <ak...@sh...> - 2002-08-11 00:44:33
|
Hello Everyone,
I've checked in the following patch to the CVS that allows Emacs to be
started correctly as a GUI application from the terminal on Mac OS X.
Therefore command line options can now be passed to Emacs. The OS X
loader still requires a pathname to the executable in the bundle be
typed to the shell for Emacs to correctly find its resources.
Now that this problem is solved, I will soon be changing
src/makefile.in to install the executable only at one place (within
the application bundle in its usual place, which is placed in say
/Applications/ or some other location specified by the user). The
`executable' in $prefix/bin/ will really be just something like the
following script:
#!/bin/sh
/Applications/Emacs.app/Contents/MacOS/Emacs $*
When invoked from the command line, it will start a GUI or terminal
version depending on whether the -nw switch is used.
Of course one can still double-click on the application bundle in the
Finder to start Emacs.
I invite everyone to test this patch.
Andrew.
-----
2002-08-10 Andrew Choi <ak...@sh...>
* mac.c (sys_select) [MAC_OSX]: New function.
* macterm.c (MakeMeTheFrontProcess): New function.
(mac_initialize): Call MakeMeTheFrontProcess.
* s/darwin.h: Define select to sys_select.
|
|
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: <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 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: 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: Andrew C. <ak...@sh...> - 2002-08-08 07:29:48
|
> > Of course this leaves the problem of M-h and the other M- keys, > > which you prefer not to pass to the Toolbox, and all the C- and > > C-S- keys, which Toshikazu prefers not to pass along to the > > Toolbox, and M-SPC, which should be passed to the Toolbox. I > > would not mind working out new Lisp variables to treat the > > disabling of M- and C- keys as special cases, rather than choosing > > one behavior or another as the default behavior. > > What kind of lisp variables do you think there should be? Hi Steven, To be consistent with names used by the w32 code, how about something called mac-pass-meta-to-system and mac-pass-control-to-system (nil and non-nil values with obvious meanings; default value t)? Andrew. |
|
From: Steven T. <ste...@ma...> - 2002-08-08 02:00:23
|
This is getting more complicated the more I look at it. As this convoluted email will show... > In the interest of keeping this simple model, I am inclined to suggest > that all key strokes be passed to the Toolbox, and Emacs receives > whatever is output. Tried a bunch of different things to see if using kEventTextInputUnicodeForKeyEvent for keyboard input would be better. This is the Mac OS X way, but being only Unicode seems that it is quite geared towards ATSUI and MLTE. This means that the application needs to convert the Unicode to the current text encoding all the time (even if using the Roman keyboard). After working with Java for a few years, I like Unicode and think this is probably a good thing. However, the complexity seems to pile up. 1. You need to support the TSM in the application. Right now it creates a TSM Document for each window. This is probably OK, but it makes the keyboard in use window dependent. So one window would be set for Japanese, and the other for U.S. This can be changed. 2. When you get Unicode, you need to check the source key to see if it was a "special" character (like arrows), and if so use that. Then you need to check to see if the meta or control key was down. 3. You need to convert the unicode to the current keyboard encoding. Preferably, it would use the current encoding of the buffer, but that would require a massive translation table between MULE encoding strings and TSM constants. In any case, I haven't been able to get this to work right. 4. kEventTextInputUnicodeForKeyEvent is only available through an EventHandler, so keyboard characters need to be posted out of bounds using kbd_buffer_store_event I got something working, but a lot of things are still broken and would have to be special cased. it seems a lot of effort for not that much value right now. When 10.2 is out and the callback based Carbon Event Manager can be used, then this is more relevant. But, if anyone is interested in trying to figure it out, I have some code to start with. > Of course this leaves the problem of M-h and the other M- keys, which > you prefer not to pass to the Toolbox, and all the C- and C-S- keys, > which Toshikazu prefers not to pass along to the Toolbox, and M-SPC, > which should be passed to the Toolbox. I would not mind working out > new Lisp variables to treat the disabling of M- and C- keys as special > cases, rather than choosing one behavior or another as the default > behavior. What kind of lisp variables do you think there should be? -Steven |
|
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: Steven T. <ste...@ma...> - 2002-08-06 05:37:58
|
> Whenever there is a discussion on the use of modifier keys, everyone > seems to want a different thing. Especially me. That's why there's the mac-reverse-ctrl-meta flag. This makes the need for M-h and M-space become the need for C-h and C-space (which are much more important.). One thing that might be useful would be a set of lisp variables that controls the mapping of Mac modifier keys to emacs modifier keys (with OS X, Fn could be mapped to Hyper?). But I can imagine that is fraught with peril. > Since there were very few choices before (without writing a lot of > code, i.e.), the existing Classic Event Handler code receives whatever > was output after all the processing the Toolbox has performed on the > input. This presents a nice, simple model to the user since the > keyboard and toolbox together can be viewed as an "virtual input > device" that sends characters in different encodings, depending on the > setting in the Keyboard control panel. This model is still possible. Instead of trying to process keyDown and autoKey classic events, you process kEventTextInputUnicodeForKeyEvent. This seems to be the preferred way of handling these things anyway, and when Jaguar comes out and the multithreaded UI is used, it will probably be the only way. In addition, we can probably get rid of all the script translation code. > This is also why even though M-SPC is a useful key in Emacs, I did not > try to find a way to circumvent the toolbox's handling of > command-space as the script switching key. > > In the interest of keeping this simple model, I am inclined to suggest > that all key strokes be passed to the Toolbox, and Emacs receives > whatever is output. It makes sense for me. One thing that may be nice out of this is the ability to use the Unicode Extended Latin keyboard. This would allow people to "auto-switch" to the Symbol and Dingbat's fonts. > Of course this leaves the problem of M-h and the other M- keys, which > you prefer not to pass to the Toolbox, and all the C- and C-S- keys, > which Toshikazu prefers not to pass along to the Toolbox, and M-SPC, > which should be passed to the Toolbox. I would not mind working out > new Lisp variables to treat the disabling of M- and C- keys as special > cases, rather than choosing one behavior or another as the default > behavior. So a new variable called something like "mac_send_ctrl_meta_to_tsm" with the default being t. If you set it to nil, Emacs will intercept the keydown event if it is a M- or C- key. I'll work on it tomorrow. In the future, emacs will have to use the Unicode stuff for text input, so it might as well be there now. -Steven |
