Thread: RE: [Mac-emacs-devel] Patch for Mouse-wheel
Brought to you by:
akochoi
Menu
▾
▴
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: 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: Steven T. <ste...@ma...> - 2002-08-05 21:02:48
Attachments:
tsm.patch
|
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: 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-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-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: 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: 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 |
|
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: 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. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X