mac-emacs-devel Mailing List for Emacs for Mac OS 8/9 (Page 2)
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-08-06 04:48:37
|
Hi Steven, Thank you for working out a fix so quickly. Whenever there is a discussion on the use of modifier keys, everyone seems to want a different thing. 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 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. 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. Does this seem acceptable to you? Andrew. |
|
From: Toshikazu O. <ohnishi@a.phys.nagoya-u.ac.jp> - 2002-08-06 02:12:23
|
>The problem with leaving it as (1) is when command-key-is-meta set to
>t. In that case, M-h never gets sent to emacs, but instead is sent to
>the application menu and causes emacs to hide. It's not a standard
>binding, but I use it and I didn't want to prohibit it. But in your
>case, it seems that command_key_is_meta is nil, so at the very least it
>should be...
>
> if (NILP( Vmac_command_key_is_meta) || !(er.modifiers & cmdKey)) {
>
>And next time I'll put the left brace on the next line to follow the
>coding standard..
I use Unix (Solaris) basically, so that I have been using the original key
sequence for the consistency..
Anyway, sending all the command key to TSM is not a good idea. However, it
is a good idea that at least only the command+space is sent to TSM even if
you set command-key-is-meta because it is used as script switching. (is
Meta-space assigned to something normally?)
>The test you gave would send everything but C- and C-S- to the event
>manager. I don't know the best way to go here. It appears that control
>key sequences (at least C-S-) are used by the input methods to specify
>something and I don't know enough to say whether or not they should
>supercede emacs control-key sequences in general. My ignorance of asian
>languages is showing. Was this possible before, without
>USE_CARBON_EVENTS?
Sorry. I misunderstood, and am little bit confused. All the un-assigned
key by an input method are/were sent to emacs as they are. So, even
without USE_CARBON_EVENTS, the C- keys are functional on emacs (in my case).
Maybe there is no need to make new variable for it. The problem is that
when I use like Meta-x or C-x u (undo), the x or u is passed to TSM, and a
floating window pops up when Japanese mode. This is sometimes annoying for
me. In this case, the solution would be that when we enter the "command" (
not searching words etc.) invoked by like M- in mini-buffer-window, all the
key are sent to emacs directly (I think there is no command in Japanese).
I don't know whether it is possible or not. Anyway, only if the command-space
is passed to TSM, the function for the key typing is almost the same as
that for the previous version without USE_CARBON_EVENTS.
Toshikazu Onishi
|
|
From: Steven T. <ste...@ma...> - 2002-08-06 00:57:49
|
> I tried the patch and found that I can enter Japanese characters through
> Japanese Input Method. However, the script switching key, i.e,
> command+space, doesn't work. It is natural that command keyboard
> events directly passes to ReceiveNextEvent as you wrote.
>
> I changed the line;
> if (!(er.modifiers & cmdKey)) {
> to
> if(1){
> then the command+space worked.
The problem with leaving it as (1) is when command-key-is-meta set to
t. In that case, M-h never gets sent to emacs, but instead is sent to
the application menu and causes emacs to hide. It's not a standard
binding, but I use it and I didn't want to prohibit it. But in your
case, it seems that command_key_is_meta is nil, so at the very least it
should be...
if (NILP( Vmac_command_key_is_meta) || !(er.modifiers & cmdKey)) {
And next time I'll put the left brace on the next line to follow the
coding standard...
> By the way,
> I also tried to change the above line to
> if (!(er.modifiers & controlKey) || (er.modifiers & cmdKey) ||
> (er.modifiers & optionKey)) {
>
> This is very useful for me because only the contorl+key event is
> directly
> send to the event manager, so that I don't need to switch from Japanese
> mode
> to Roman mode when I would like to issue control+key command in emacs.
> If someone assigns the control+key sequence to some Japanese input
> method functions,
> there will be some problems.
The test you gave would send everything but C- and C-S- to the event
manager. I don't know the best way to go here. It appears that control
key sequences (at least C-S-) are used by the input methods to specify
something and I don't know enough to say whether or not they should
supercede emacs control-key sequences in general. My ignorance of asian
languages is showing. Was this possible before, without
USE_CARBON_EVENTS?
One possible solution would be to introduce yet another variable, like
"mac-ctrl-to-tsm", which would determine whether C- and C-S- key
sequences would go to the TSM (and change the pen menu) or go directly
to emacs. Or there could be a lisp function that can send a keyboard
event back to the event manager, so if specific control keys should be
made to call back to the script menu. What do other people think?
-Steven
|
|
From: Toshikazu O. <ohnishi@a.phys.nagoya-u.ac.jp> - 2002-08-05 22:03:37
|
Hi,
Thank you for the quick response.
I tried the patch and found that I can enter Japanese characters through
Japanese Input Method. However, the script switching key, i.e,
command+space, doesn't work. It is natural that command keyboard
events directly passes to ReceiveNextEvent as you wrote.
I changed the line;
if (!(er.modifiers & cmdKey)) {
to
if(1){
then the command+space worked.
I don't know for sure that this modification introduces another bug, although
it seems fine for me.
By the way,
I also tried to change the above line to
if (!(er.modifiers & controlKey) || (er.modifiers & cmdKey) || (er.modifiers & optionKey)) {
This is very useful for me because only the contorl+key event is directly
send to the event manager, so that I don't need to switch from Japanese mode
to Roman mode when I would like to issue control+key command in emacs.
If someone assigns the control+key sequence to some Japanese input method functions,
there will be some problems.
Toshikazu Onishi
|
|
From: Steven T. <ste...@ma...> - 2002-08-05 21:02:48
|
Here is the patch to macterm.c. The main part is to try to pass non-command keyboard events to the system first and check to see if the TSM intercepted it. If so, then it ignores the event, otherwise it tries to post it to the screen. The "right thing" to do would be to accept Unicode events, but that will probably have to wait for Jaguar (but that is another email). I also tried to test the input method floating window and ran into a lot of crashes where emacs tries to treat it like another frame and crashed. Most of the bulk of the patch is using is_emacs_window() liberally and replacing FrontWindow() with FrontNonFloatingWindow(). |
|
From: Steven T. <ste...@ma...> - 2002-08-05 17:46:04
|
I see the problem. The input method window isn't appearing when you type in text in CJKV. I'm currently pouring over the carbon docs regarding text input to see what I have to do to get the keyDown events to be intercepted by text services. Apple seems to be gearing more towards adoption of unicode input. I may try and look into getting Emacs to accept unicode and convert based on the current encoding, that way the Extended Roman keyboard would work. Thanks for trying it out. -Steven On Sunday, August 4, 2002, at 09:30 PM, Toshikazu Onishi wrote: > Hi, > >> I have just checked in to the CVS a very nice patch contributed by >> Steven Tamm which lets Emacs recognize 2- and 3-button and wheel mice. >> Attached below is his description of it, among other things. > > The wheel mice support is found to be quite nice, but I found that > this patch disables Japanese input method. "command+space" to switch > to Japanese mode doesn't work. > > Commenting out "#define USE_CARBON_EVENTS 1" solves the problem, so that > ReceiveNextEvent seems to perform nothing for the input method. > > Toshikazu Onishi > > > ------------------------------------------------------- > 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: Toshikazu O. <ohnishi@a.phys.nagoya-u.ac.jp> - 2002-08-05 04:30:04
|
Hi, >I have just checked in to the CVS a very nice patch contributed by >Steven Tamm which lets Emacs recognize 2- and 3-button and wheel mice. >Attached below is his description of it, among other things. The wheel mice support is found to be quite nice, but I found that this patch disables Japanese input method. "command+space" to switch to Japanese mode doesn't work. Commenting out "#define USE_CARBON_EVENTS 1" solves the problem, so that ReceiveNextEvent seems to perform nothing for the input method. Toshikazu Onishi |
|
From: Andrew C. <ak...@sh...> - 2002-08-04 19:37:13
|
This fixes the problem that Emacs crashes on Mac OS X when a key is hit and there is no front window. 2002-08-04 Andrew Choi <ak...@sh...> * macterm.c (XTread_socket): Check that FrontNonFloatingWindow returns a valid window pointer before proceeding for keyDown and autoKey events. |
|
From: <ja...@sw...> - 2002-08-04 11:57:46
|
s=F6ndagen den 4 augusti 2002 kl 11.27 skrev Jan Dj=E4rv: > > s=F6ndagen den 4 augusti 2002 kl 01.53 skrev Andrew Choi: > >> Hi Everyone, >> >> I have just checked in to the CVS a very nice patch contributed by >> Steven Tamm which lets Emacs recognize 2- and 3-button and wheel = mice. >> Attached below is his description of it, among other things. >> >> Also recently changed in the CVS is the creator code of the Emacs >> application from ???? to EMAx. > > This version dies instantly for me. Even emacs -nw dies. Here is a=20= > backtrace, I can debug some more if that helps. I did: > ./configure --prefix=3D/usr/local --verbose --with-x=3Dno > make bootstrap Nevermind, I did everything from scratch again, and now it is OK. Jan D. |
|
From: <ja...@sw...> - 2002-08-04 09:28:50
|
s=F6ndagen den 4 augusti 2002 kl 01.53 skrev Andrew Choi: > Hi Everyone, > > I have just checked in to the CVS a very nice patch contributed by > Steven Tamm which lets Emacs recognize 2- and 3-button and wheel mice. > Attached below is his description of it, among other things. > > Also recently changed in the CVS is the creator code of the Emacs > application from ???? to EMAx. This version dies instantly for me. Even emacs -nw dies. Here is a=20 backtrace, I can debug some more if that helps. I did: ./configure --prefix=3D/usr/local --verbose --with-x=3Dno make bootstrap Program received signal EXC_BAD_ACCESS, Could not access memory. 0x79005ae0 in ?? () (gdb) where #0 0x79005ae0 in ?? () Cannot access memory at address 0x79005ae0 #1 0x00106048 in unexec_realloc (old_ptr=3D0x6e0110, new_size=3D41) at=20= unexmacosx.c:891 #2 0x00005f0c in adjust_frame_message_buffer (f=3D0x6dfdd0) at = dispnew.c:2435 #3 0x000058ac in adjust_frame_glyphs (f=3D0x6dfdd0) at dispnew.c:2133 #4 0x00005854 in adjust_frame_glyphs_initially () at dispnew.c:2115 #5 0x0000cb18 in init_display () at dispnew.c:6478 #6 0x00066a84 in main (argc=3D1, argv=3D0xbffff74c, envp=3D0x488) at = emacs.c:1528 #7 0x00003668 in _start () #8 0x00003498 in start () (gdb) Jan D. |
|
From: Andrew C. <ak...@sh...> - 2002-08-03 23:54:10
|
Hi Everyone, I have just checked in to the CVS a very nice patch contributed by Steven Tamm which lets Emacs recognize 2- and 3-button and wheel mice. Attached below is his description of it, among other things. Also recently changed in the CVS is the creator code of the Emacs application from ???? to EMAx. Andrew. ----- > The main part of this patch is to switch the event handling loop in > XTread_socket from using the Mac OS 9 style WaitNextEvent to using the > preferred carbon method ReceiveNextEvent. This allows the following to > be supported: > > 1. Mouse button support > Keyboard Modifiers now sent with mouse button events > Right mouse button reported as mouse-2. Third mouse button or > mouse-wheel button reported as mouse-3. This mapping is customizable. > > 2. Mouse wheel support. > Mouse-wheel events are sent out using the Windows-NT style > [mouse-wheel] event style. Changes to mac-win.el included here use > mwheel.el to support auto scrolling. > > 3. Drag and drop support onto frames. > Drag a file from the finder onto a specific buffer and it will > autoload the buffer. > > 4. Preliminary OSX Services menu support > Currently only supports reading the last thing yanked (or current > selection). So you can highlight a URL and invoke the "Open URL in > OmniWeb" menu from the services menu. I'd really like developers more > familiar with emacs-kill ring to try and give this a look, since it > currently relies on the clipboard which is not the best. > > 5. Iconify-frame now collapses the window into the dock. > Changes to mac-win.el to map C-z to "iconify" the frame to the dock. > Currently this doesn't mark the window as actually being iconified in > emacs. I'm not sure this is the right thing to do. > > 6. M-h now available since command-h key doesn't automatically turn > into invoking "Hide Emacs" > > Most of these changes are guarded by a #ifdef variable called > USE_CARBON_EVENTS which defaults to being on. If this is commented out, > the support for drag and drop and keyboard modifiers on mouse events are > still supported. > > > Here are the new variables added: > mac-reverse-ctrl-meta. If t, causes the control and meta keys to be > reversed. The default is nil. For people using PC keyboards mapped to > the Mac, this is quite beneficial. Note, this cannot be extended to > switching caps lock and control. I tried. > > 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. |
|
From: Andrew C. <ak...@sh...> - 2002-08-02 19:34:24
|
> I have changed the posix_to_mac_pathname and mac_to_posix_pathname > functions in mac.c to use the CFxxx functions so that they are > properly aware of mount points etc. My emacs has been working > properly with these for about a week. > Immanuel. > [...] Hi Immanuel, Thank you for sending the patch. But can you please tell me what is the problem that it solves? I am able to access DiskCopy-mounted volumes and my iDisk in the current version in /Volumes/. Andrew. |
|
From: Andrew C. <ak...@sh...> - 2002-08-01 03:41:52
|
Hi Nozomu, Thanks! This is a very nice patch. I've checked this into the CVS and added your installation instructions below to the file mac/INSTALL. Andrew. [I have not tested this patch because I do not have X Window on my Mac. I invite everyone interested to try it.] > Hi, > > I had to compile emacs of current CVS tree with X window support on > MacOSX. But > > ./configure --with-x --without-carbon > > did not work. I think there are two problems. > > P1. Some symbols conflict between code for X and code for Carbon. > P2. Even when the abobe problem is solved, temacs linked with X dynlib > cannot unexec. > > To solve the problem 1, I made small patch attached to this mail. > > I think I cannot solve the problem 2. But there is workaround. e.g.: > > W2a. make directory contains only statically-linked X library. > % sudo mkdir /usr/X11R6/libstatic > % cd /usr/X11R6/libstatic > % sudo ln -s ../lib/lib*.a ../lib/X11 . > W2b. configure Emacs with the libraries. > % ./configure --without-carbon --with-x --x- > libraries=/usr/X11R6/libstatic > > This emacs on XDarwin also works fine for me. > > I hope this helps. > > Nozomu Ando > ----- > > Index: src/s/darwin.h > =================================================================== > RCS file: /cvsroot/emacs/emacs/src/s/darwin.h,v > retrieving revision 1.3 > diff -u -r1.3 darwin.h > --- src/s/darwin.h 1 Jul 2002 23:30:21 -0000 1.3 > +++ src/s/darwin.h 9 Jul 2002 08:21:26 -0000 > @@ -40,8 +40,10 @@ > /* MAC_OS is used to conditionally compile code common to both MAC_OS8 > and MAC_OSX. */ > #ifdef MAC_OSX > +#ifdef HAVE_CARBON > #define MAC_OS > #endif > +#endif > > /* SYSTEM_TYPE should indicate the kind of system you are using. > It sets the Lisp variable system-type. */ > @@ -222,7 +224,9 @@ > #define HAVE_SOCKETS > > /* Extra initialization calls in main for Mac OS X system type. */ > +#ifdef HAVE_CARBON > #define SYMS_SYSTEM syms_of_mac() > +#endif > > /* Definitions for how to dump. Copied from nextstep.h. */ > > @@ -271,7 +275,9 @@ > > /* Tell src/Makefile.in to create files in the Mac OS X application > bundle mac/Emacs.app. */ > +#ifdef HAVE_CARBON > #define OTHER_FILES macosx-app > +#endif > > > /* Define the following so emacs symbols will not conflict with those |
|
From: d p c. <we...@me...> - 2002-07-31 15:54:47
|
things seem to be working ok for me, but it appears that the macos x getaddrinfo fails sometimes in a way that i haven't quite nailed down (not that i've really tried to hard) when using gnus (i haven't tested a lot of other apps). Anyway, changing this in config.h makes gnus happy \p --- Can you imagine if carpenters were like computer scientists? Some of them would argue that it's not necessary to own a hammer because the butt of a screwdriver is naildriver-complete. --- Barry Margolin (c.l.l.) |
|
From: Immanuel L. <imm...@en...> - 2002-07-29 10:27:00
|
I have changed the posix_to_mac_pathname and mac_to_posix_pathname
functions in mac.c to use the CFxxx functions so that they are
properly aware of mount points etc. My emacs has been working
properly with these for about a week.
Immanuel.
#ifdef MAC_OSX
int
posix_to_mac_pathname(const char* ufn, char *mfn, int mfnbuflen)
{
CFStringRef thePosixPath = CFStringCreateWithCString(NULL,
ufn,
kCFStringEncodingMacRoman);
CFURLRef theURLRef = CFURLCreateWithFileSystemPath(kCFAllocatorDefault,
thePosixPath,
kCFURLPOSIXPathStyle,
false);
CFStringRef theMacPath = CFURLCopyFileSystemPath(theURLRef,
kCFURLHFSPathStyle);
CFStringGetCString(theMacPath,
mfn,
mfnbuflen,
kCFStringEncodingMacRoman);
CFRelease(theMacPath);
CFRelease(theURLRef);
CFRelease(thePosixPath);
return true;
}
mac_to_posix_pathname(const char* mfn, char* ufn, int ufnbuflen)
{
CFStringRef theMacPath = CFStringCreateWithCString(NULL,
mfn,
kCFStringEncodingMacRoman);
CFURLRef theURLRef = CFURLCreateWithFileSystemPath(kCFAllocatorDefault,
theMacPath,
kCFURLHFSPathStyle,
false);
CFStringRef thePosixPath = CFURLCopyFileSystemPath(theURLRef,
kCFURLPOSIXPathStyle);
CFStringGetCString(thePosixPath,
ufn,
ufnbuflen,
kCFStringEncodingMacRoman);
CFRelease(theMacPath);
CFRelease(theURLRef);
CFRelease(thePosixPath);
return true;
}
#else // old functions
***************************************************************************
His endeavours to improve these conditions by innovations in the
current methods of teaching are fully described in his writings; these
made him unpopular with his brethren in the order and led to his
removals to the monastery of Pomposa near Ferrara, Italy. Here the
same lot seems to have befallen him.
About Guido of Arezzo
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: Steven T. <ste...@ma...> - 2002-07-20 06:56:16
|
While Andrew's on vacation, I figured I'd send this patch out to the
list to get people trying it out.
The main part of this patch is to switch the event handling loop in
XTread_socket from using the Mac OS 9 style WaitNextEvent to using the
preferred carbon method ReceiveNextEvent. This allows the following to
be supported:
1. Mouse button support
Keyboard Modifiers now sent with mouse button events
Right mouse button reported as mouse-2. Third mouse button or
mouse-wheel button reported as mouse-3. This mapping is customizable.
2. Mouse wheel support.
Mouse-wheel events are sent out using the Windows-NT style
[mouse-wheel] event style. Changes to mac-win.el included here use
mwheel.el to support auto scrolling.
3. Drag and drop support onto frames.
Drag a file from the finder onto a specific buffer and it will
autoload the buffer.
4. Preliminary OSX Services menu support
Currently only supports reading the last thing yanked (or current
selection). So you can highlight a URL and invoke the "Open URL in
OmniWeb" menu from the services menu. I'd really like developers more
familiar with emacs-kill ring to try and give this a look, since it
currently relies on the clipboard which is not the best.
5. Iconify-frame now collapses the window into the dock.
Changes to mac-win.el to map C-z to "iconify" the frame to the dock.
Currently this doesn't mark the window as actually being iconified in
emacs. I'm not sure this is the right thing to do.
6. M-h now available since command-h key doesn't automatically turn
into invoking "Hide Emacs"
Most of these changes are guarded by a #ifdef variable called
USE_CARBON_EVENTS which defaults to being on. If this is commented out,
the support for drag and drop and keyboard modifiers on mouse events are
still supported.
Here are the new variables added:
mac-reverse-ctrl-meta. If t, causes the control and meta keys to be
reversed. The default is nil. For people using PC keyboards mapped to
the Mac, this is quite beneficial. Note, this cannot be extended to
switching caps lock and control. I tried.
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.
|
|
From: Andrew C. <ak...@sh...> - 2002-07-20 03:24:06
|
> The output buffers from subordinate processes (in my case, latex) > loose the final parts -- this was fixed a while ago, but it is > broken again. This functionality is crucial for latex users, since > the package auctex captures the output from that buffers to make > decisions. Can somebody suggest a patch I could test? > > A further request to Andrew: could you decide for a creator code for > the app? Without it, we can not use, e.g., USB Overdrive to set > mouse bindings. As far as I can remember, "EMAx" was used once; I > think this can be reused. It is enough to modify the file PkgInfo > to: APPLEMAx > > cheers > -- e. Hi Enrico, For a fix for the subprocess problem, please see Nozomu's message. I'm in the middle of a two-week vacation. I'll fix the creator code when I come back, in a week or so. EMAx can certainly be used: I've registered it for use by Emacs. Andrew. |
|
From: Steven T. <ste...@ma...> - 2002-07-19 08:32:35
|
After much digging I found a way to move the mouse cursor around programmatically in Mac OS X, despite the documentation of CursorDeviceMoveTo saying you could not. In Quartz 2D, they added the ability to directly modify the screen, including setting the position of the cursor. The documentation can be found in a technote here http://developer.apple.com/technotes/tn/tn2007.html I'm running 10.1.5, so that's all I can vouch for. To try it out you can simple eval (set-mouse-position (selected-frame) 10 10) and it should jump the cursor 10 lines down and 10 characters over. If you remove the call to ObscureCursor in XTread_socket it will be more dramatic. mouse-avoidance-mode is even more clever. Replace the implementation of x_set_mouse_pixel_position in macterm.c (around line 9923 in my version) to be this... void x_set_mouse_pixel_position (f, pix_x, pix_y) struct frame *f; int pix_x, pix_y; { #if MAC_OSX CGPoint point; Point pt; Rect r; GrafPtr savePort; BLOCK_INPUT; GetPort(&savePort); #if TARGET_API_MAC_CARBON SetPort (GetWindowPort (FRAME_MAC_WINDOW (f))); #else SetPort (FRAME_MAC_WINDOW (f)); #endif GetWindowPortBounds (FRAME_MAC_WINDOW (f), &r); SetPt(&pt, r.left, r.top); LocalToGlobal(&pt); SetPort (savePort); /* Use Quartz 2d Direct Display API to move cursor. Not sure if this works on OS X 10.0 */ point = CGPointMake(pt.h+pix_x, pt.v+pix_y); CGDisplayMoveCursorToPoint(kCGDirectMainDisplay, point); UNBLOCK_INPUT; #endif /* MAC_OSX */ } Thanks for reading, -Steven |
|
From: Steven T. <ste...@ma...> - 2002-07-18 18:11:07
|
To modify the creator code, You also have to change the Info.plist for it to correctly work. <key>CFBundleSignature</key> <string>????</string> should be replaced with <key>CFBundleSignature</key> <string>EMAx</string> You also have to modify PkgInfo. -Steven On Thursday, July 18, 2002, at 01:54 AM, Enrico Franconi wrote: > The output buffers from subordinate processes (in my case, latex) > loose the final parts -- this was fixed a while ago, but it is broken > again. This functionality is crucial for latex users, since the > package auctex captures the output from that buffers to make > decisions. Can somebody suggest a patch I could test? > > A further request to Andrew: could you decide for a creator code for > the app? Without it, we can not use, e.g., USB Overdrive to set mouse > bindings. As far as I can remember, "EMAx" was used once; I think this > can be reused. It is enough to modify the file PkgInfo to: > APPLEMAx > > cheers > -- e. > > Enrico Franconi - fra...@in... > Free University of Bozen-Bolzano - http://www.inf.unibz.it/~franconi/ > Faculty of Computer Science - Phone: (+39) 0471-315-642 > I-39100 Bozen-Bolzano BZ, Italy - Fax: (+39) 0471-315-649 > > > ------------------------------------------------------- > 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: Enrico F. <fra...@cs...> - 2002-07-18 12:08:27
|
On July 18, Nozomu Ando writes: > > The output buffers from subordinate processes (in my case, latex) > > loose the final parts -- this was fixed a while ago, but it is > > broken again. This functionality is crucial for latex users, since > > the package auctex captures the output from that buffers to make > > decisions. Can somebody suggest a patch I could test? > > please try > > (setq process-connection-type nil) > > in .emacs. This worked. Thanks -- e. Enrico Franconi - fra...@in... Free University of Bozen-Bolzano - http://www.inf.unibz.it/~franconi/ Faculty of Computer Science - Phone: (+39) 0471-315-642 I-39100 Bozen-Bolzano BZ, Italy - Fax: (+39) 0471-315-649 |
|
From: Nozomu A. <na...@ma...> - 2002-07-18 09:59:32
|
Hi, Enrico, On 2002.07.18, at 17:54, Enrico Franconi wrote: > The output buffers from subordinate processes (in my case, latex) > loose the final parts -- this was fixed a while ago, but it is broken > again. This functionality is crucial for latex users, since the > package auctex captures the output from that buffers to make > decisions. Can somebody suggest a patch I could test? please try (setq process-connection-type nil) in .emacs. In lisp/term/mac-win.el, the variable set by the following code: (unless (eq system-type 'darwin) ;; Tell Emacs to use pipes instead of pty's for processes because the ;; latter sometimes lose characters. Pty support is compiled in since ;; ange-ftp will not work without it. (setq process-connection-type nil)) But pty on MacOSX (or at least on build 5S66) is buggy. So I think the above code should be simply (setq process-connection-type nil) or (if (eq system-type 'darwin) (setq process-connection-type nil)) I hope it helps. Regards, Nozomu Ando |
|
From: Enrico F. <fra...@cs...> - 2002-07-18 08:56:14
|
The output buffers from subordinate processes (in my case, latex) loose the final parts -- this was fixed a while ago, but it is broken again. This functionality is crucial for latex users, since the package auctex captures the output from that buffers to make decisions. Can somebody suggest a patch I could test? A further request to Andrew: could you decide for a creator code for the app? Without it, we can not use, e.g., USB Overdrive to set mouse bindings. As far as I can remember, "EMAx" was used once; I think this can be reused. It is enough to modify the file PkgInfo to: APPLEMAx cheers -- e. Enrico Franconi - fra...@in... Free University of Bozen-Bolzano - http://www.inf.unibz.it/~franconi/ Faculty of Computer Science - Phone: (+39) 0471-315-642 I-39100 Bozen-Bolzano BZ, Italy - Fax: (+39) 0471-315-649 |
|
From: Bruce I. <bin...@fi...> - 2002-07-12 21:55:15
|
I have posted a recent version of EMacro, an easy to use & install .emacs at <url: http://emacro.sf.net/ > It does work with some versions of Emacs on Mac OS Classic (8-9) and OS X. I hope to make EMacro a standard amongst .emacsen. However, I do need help from the Mac Emacs community. I've pretty much given up on XEmacs support for Mac, as there are no recent ports. I tried installing it with the precompiled binary of <url: http://Emacs-On-Aqua.sf.net/ > However, that release has several bugs. Since Mac Emacs v21 supports Carbon, does this mean that I should not waste my time trying to support Emacs-On-Aqua? EMacro docs are written in XHTML. I've added an EMacro submenu to Emacs's help menu. I wrote hard coded elisp/applescript to launch Netscape, which works nicely. Unfortunately, I am not very good at AppleScript, and I don't know how to launch the default Mac browser, nor otherwise how to discover if IE or other browsers are available, and where. If someone does get the above code working, it would be good to donate to browse-url.el I also don't know how to deal with keybinding problems, such as the 'End' key issuing C-k or other reserved Emacs keybinding. Finally, it would be nice to know how to package EMacro for Mac distribution, such as dmg files. I do have Unix shell scripts, and Dos batch files, which simply rename ~/init.el to ~/.emacs, to prevent tromping on an user's existing .emacs file. I'd appreciate a donated Applescript, if such makes sense. I reckon shell script suffices for OS X users. With your help, Emacs will become an easier & popular part of the Mac experience. -- EMacro remakes Emacs http://emacro.sf.net/ NY Harbor 2001-9-11 http://www.fit-zones.com/911/ |
|
From: Nozomu A. <na...@ma...> - 2002-07-09 08:53:00
|
Hi, I had to compile emacs of current CVS tree with X window support on MacOSX. But ./configure --with-x --without-carbon did not work. I think there are two problems. P1. Some symbols conflict between code for X and code for Carbon. P2. Even when the abobe problem is solved, temacs linked with X dynlib cannot unexec. To solve the problem 1, I made small patch attached to this mail. I think I cannot solve the problem 2. But there is workaround. e.g.: W2a. make directory contains only statically-linked X library. % sudo mkdir /usr/X11R6/libstatic % cd /usr/X11R6/libstatic % sudo ln -s ../lib/lib*.a ../lib/X11 . W2b. configure Emacs with the libraries. % ./configure --without-carbon --with-x --x- libraries=/usr/X11R6/libstatic This emacs on XDarwin also works fine for me. I hope this helps. Nozomu Ando |
|
From: Andreas S. <sc...@su...> - 2002-07-04 20:37:46
|
Andrew Choi <ak...@sh...> writes: |> Hi, |> |> I've just added the file mac/make-package to the CVS tree. |> |> This is shell script contributed by Steven Tamm. When run, it creates |> an Installer package file containing the files needed by Emacs. The |> Installer application can then be used to install them. |> |> Please test this and let me know if it works for you. Can this be changed to not clutter up the source directory? Currently the script runs configure and make in the source directory. Why not use an existing build tree? I prefer to keep the source tree as clean as possible, so I always build in a separate directory. 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." |
