* bug#8680: Cocoa Emacs not mapping Clear key on aluminum keyboards. @ 2011-05-17 5:07 Michael Marchionna 2011-05-17 17:34 ` bug#8680: nsterm.m does not distinguish key on the key pad Michael Marchionna ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: Michael Marchionna @ 2011-05-17 5:07 UTC (permalink / raw) To: 8680 The newer Mac aluminum keyboards have a "clear" on the keypad group where the Num-Lock typically lives. This key generates: keyCode: 71 (0x47), and character: 0xf739. The character 0xf739 maps to the NSClearLineFunctionKey defined in NSEvent.h. Since this symbol is not listed in the nsterm.m translation table the clear key becomes a dead key. It can be mapped to emacs [clear] key with the following change. diff --git a/src/nsterm.m b/src/nsterm.m index 91f0cbb..119327d 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -87,6 +87,7 @@ static unsigned convert_ns_to_X_keysym[] = NSBeginFunctionKey, 0x58, NSSelectFunctionKey, 0x60, NSPrintFunctionKey, 0x61, + NSClearLineFunctionKey, 0x0B, NSExecuteFunctionKey, 0x62, NSInsertFunctionKey, 0x63, NSUndoFunctionKey, 0x65, This change makes the key respond as it did in Carbon Emacs. ^ permalink raw reply related [flat|nested] 16+ messages in thread
* bug#8680: nsterm.m does not distinguish key on the key pad 2011-05-17 5:07 bug#8680: Cocoa Emacs not mapping Clear key on aluminum keyboards Michael Marchionna @ 2011-05-17 17:34 ` Michael Marchionna 2012-11-04 3:34 ` Chong Yidong 2011-05-23 20:11 ` bug#8680: emacs 24.0 OS X keypad patch Michael Marchionna 2013-12-10 22:13 ` bug#8680: Bug #8680 Andrew Stein 2 siblings, 1 reply; 16+ messages in thread From: Michael Marchionna @ 2011-05-17 17:34 UTC (permalink / raw) To: 8680 In addition to the clear/NumLock key not being mapped the rest of the keypad keys do not seem to be translated as well, and hence can not be distinguished from keys on the main keyboard. What follows is a patch that remaps the keypad keys. at least on a aluminum apple keyboard, to the appropriate X11 virtual key codes. Note the Clear/NumLock key is hardcoded to XK_Clear. There should probably be a way to make it possible to configure it so that it translates to XK_Num_Lock. diff --git a/src/nsterm.m b/src/nsterm.m index 91f0cbb..322c9d9 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -87,6 +87,7 @@ static unsigned convert_ns_to_X_keysym[] = NSBeginFunctionKey, 0x58, NSSelectFunctionKey, 0x60, NSPrintFunctionKey, 0x61, + NSClearLineFunctionKey, 0x0B, NSExecuteFunctionKey, 0x62, NSInsertFunctionKey, 0x63, NSUndoFunctionKey, 0x65, @@ -131,7 +132,24 @@ static unsigned convert_ns_to_X_keysym[] = NSNewlineCharacter, 0x0D, NSEnterCharacter, 0x8D, - 0x1B, 0x1B /* escape */ + 0x1B, 0x1B, /* escape */ + + 0x41, 0xAE, /* KP_Decimal */ + 0x43, 0xAA, /* KP_Multiply */ + 0x45, 0xAB, /* KP_Add */ + 0x4B, 0xAF, /* KP_Divide */ + 0x4E, 0xAD, /* KP_Subtract */ + 0x51, 0xBD, /* KP_Equal */ + 0x52, 0xB0, /* KP_0 */ + 0x53, 0xB1, /* KP_1 */ + 0x54, 0xB2, /* KP_2 */ + 0x55, 0xB3, /* KP_3 */ + 0x56, 0xB4, /* KP_4 */ + 0x57, 0xB5, /* KP_5 */ + 0x58, 0xB6, /* KP_6 */ + 0x59, 0xB7, /* KP_7 */ + 0x5B, 0xB8, /* KP_8 */ + 0x5C, 0xB9 /* KP_9 */ }; @@ -4503,10 +4521,10 @@ ns_term_shutdown (int sig) Mouse_HLInfo *hlinfo = MOUSE_HL_INFO (emacsframe); int code; unsigned fnKeysym = 0; - int flags; static NSMutableArray *nsEvArray; static BOOL firstTime = YES; int left_is_none; + unsigned int flags = [theEvent modifierFlags]; NSTRACE (keyDown); @@ -4550,9 +4568,13 @@ ns_term_shutdown (int sig) code = ([[theEvent charactersIgnoringModifiers] length] == 0) ? 0 : [[theEvent charactersIgnoringModifiers] characterAtIndex: 0]; /* (Carbon way: [theEvent keyCode]) */ + /* is it a "function key"? */ - fnKeysym = ns_convert_key (code); + if ( code < 0x00ff && (flags&NSNumericPadKeyMask) ) + fnKeysym = ns_convert_key([theEvent keyCode]); + else + fnKeysym = ns_convert_key (code); if (fnKeysym) { /* COUNTERHACK: map 'Delete' on upper-right main KB to 'Backspace', @@ -4565,7 +4587,6 @@ ns_term_shutdown (int sig) /* are there modifiers? */ emacs_event->modifiers = 0; - flags = [theEvent modifierFlags]; if (flags & NSHelpKeyMask) emacs_event->modifiers |= hyper_modifier; ^ permalink raw reply related [flat|nested] 16+ messages in thread
* bug#8680: nsterm.m does not distinguish key on the key pad 2011-05-17 17:34 ` bug#8680: nsterm.m does not distinguish key on the key pad Michael Marchionna @ 2012-11-04 3:34 ` Chong Yidong 0 siblings, 0 replies; 16+ messages in thread From: Chong Yidong @ 2012-11-04 3:34 UTC (permalink / raw) To: Michael Marchionna; +Cc: 8680 Michael Marchionna <tralfaz@pacbell.net> writes: > In addition to the clear/NumLock key not being mapped the rest of the > keypad keys do not seem to be translated as well, and hence can not be > distinguished from keys on the main keyboard. What follows is a patch > that remaps the keypad keys. at least on a aluminum apple keyboard, to > the appropriate X11 virtual key codes. Note the Clear/NumLock key is > hardcoded to XK_Clear. There should probably be a way to make it > possible to configure it so that it translates to XK_Num_Lock. I've committed your patch to the trunk. Sorry for the long delay. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#8680: emacs 24.0 OS X keypad patch 2011-05-17 5:07 bug#8680: Cocoa Emacs not mapping Clear key on aluminum keyboards Michael Marchionna 2011-05-17 17:34 ` bug#8680: nsterm.m does not distinguish key on the key pad Michael Marchionna @ 2011-05-23 20:11 ` Michael Marchionna 2011-07-04 17:42 ` Stefan Monnier 2013-12-10 22:13 ` bug#8680: Bug #8680 Andrew Stein 2 siblings, 1 reply; 16+ messages in thread From: Michael Marchionna @ 2011-05-23 20:11 UTC (permalink / raw) To: 8680 [-- Attachment #1: Type: text/plain, Size: 240 bytes --] Adding keypad keycodes to the existing translation table leads to some keys being wrongly interpreted as keypad keys. To avoid that, this patch uses a separate translation table exclusively for keys that generate a NSNumericPadKeyMask. [-- Attachment #2: emacs-24-src-nsterm.m.patch --] [-- Type: application/octet-stream, Size: 4345 bytes --] diff --git a/src/nsterm.m b/src/nsterm.m index 91f0cbb..d537ee3 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -87,6 +87,7 @@ static unsigned convert_ns_to_X_keysym[] = NSBeginFunctionKey, 0x58, NSSelectFunctionKey, 0x60, NSPrintFunctionKey, 0x61, + NSClearLineFunctionKey, 0x0B, NSExecuteFunctionKey, 0x62, NSInsertFunctionKey, 0x63, NSUndoFunctionKey, 0x65, @@ -134,6 +135,35 @@ static unsigned convert_ns_to_X_keysym[] = 0x1B, 0x1B /* escape */ }; +static unsigned convert_nskeypad_to_X_keysym[] = +{ + /* Arrow keys are both function and keypad keys */ + NSLeftArrowFunctionKey, 0x51, + NSUpArrowFunctionKey, 0x52, + NSRightArrowFunctionKey, 0x53, + NSDownArrowFunctionKey, 0x54, + + 0x41, 0xAE, /* KP_Decimal */ + 0x43, 0xAA, /* KP_Multiply */ + 0x45, 0xAB, /* KP_Add */ + 0x4B, 0xAF, /* KP_Divide */ + 0x4E, 0xAD, /* KP_Subtract */ + 0x51, 0xBD, /* KP_Equal */ + 0x52, 0xB0, /* KP_0 */ + 0x53, 0xB1, /* KP_1 */ + 0x54, 0xB2, /* KP_2 */ + 0x55, 0xB3, /* KP_3 */ + 0x56, 0xB4, /* KP_4 */ + 0x57, 0xB5, /* KP_5 */ + 0x58, 0xB6, /* KP_6 */ + 0x59, 0xB7, /* KP_7 */ + 0x5B, 0xB8, /* KP_8 */ + 0x5C, 0xB9, /* KP_9 */ + + // The enter key is on the keypad but modifier isnt set + NSEnterCharacter, 0x8D +}; + static Lisp_Object Qmodifier_value; Lisp_Object Qalt, Qcontrol, Qhyper, Qmeta, Qsuper, Qnone; @@ -1924,13 +1954,33 @@ ns_convert_key (unsigned code) unsigned keysym; /* An array would be faster, but less easy to read. */ for (keysym = 0; keysym < last_keysym; keysym += 2) - if (code == convert_ns_to_X_keysym[keysym]) - return 0xFF00 | convert_ns_to_X_keysym[keysym+1]; + + if (code == convert_ns_to_X_keysym[keysym]) { + return 0xFF00 | convert_ns_to_X_keysym[keysym+1]; + } return 0; /* if decide to use keyCode and Carbon table, use this line: return code > 0xff ? 0 : 0xFF00 | ns_keycode_to_xkeysym_table[code]; */ } +static unsigned +ns_convert_keypad (unsigned code) +/* -------------------------------------------------------------------------- + Internal call used by NSView-keyDown. + -------------------------------------------------------------------------- */ +{ + const unsigned last_keysym = (sizeof (convert_nskeypad_to_X_keysym) + / sizeof (convert_nskeypad_to_X_keysym[0])); + unsigned keysym; + /* An array would be faster, but less easy to read. */ + for (keysym = 0; keysym < last_keysym; keysym += 2) { + if (code == convert_nskeypad_to_X_keysym[keysym]) { + return 0xFF00 | convert_nskeypad_to_X_keysym[keysym+1]; + } + } + return 0; +} + char * x_get_keysym_name (int keysym) @@ -4503,10 +4553,10 @@ ns_term_shutdown (int sig) Mouse_HLInfo *hlinfo = MOUSE_HL_INFO (emacsframe); int code; unsigned fnKeysym = 0; - int flags; static NSMutableArray *nsEvArray; static BOOL firstTime = YES; int left_is_none; + unsigned int flags = [theEvent modifierFlags]; NSTRACE (keyDown); @@ -4550,9 +4600,13 @@ ns_term_shutdown (int sig) code = ([[theEvent charactersIgnoringModifiers] length] == 0) ? 0 : [[theEvent charactersIgnoringModifiers] characterAtIndex: 0]; /* (Carbon way: [theEvent keyCode]) */ + /* is it a "function key"? */ - fnKeysym = ns_convert_key (code); + if (code < 0x00ff && (flags & NSNumericPadKeyMask) ) + fnKeysym = ns_convert_keypad([theEvent keyCode]); + else + fnKeysym = ns_convert_key(code); if (fnKeysym) { /* COUNTERHACK: map 'Delete' on upper-right main KB to 'Backspace', @@ -4565,7 +4619,6 @@ ns_term_shutdown (int sig) /* are there modifiers? */ emacs_event->modifiers = 0; - flags = [theEvent modifierFlags]; if (flags & NSHelpKeyMask) emacs_event->modifiers |= hyper_modifier; ^ permalink raw reply related [flat|nested] 16+ messages in thread
* bug#8680: emacs 24.0 OS X keypad patch 2011-05-23 20:11 ` bug#8680: emacs 24.0 OS X keypad patch Michael Marchionna @ 2011-07-04 17:42 ` Stefan Monnier 2011-07-07 3:04 ` Adrian Robert 0 siblings, 1 reply; 16+ messages in thread From: Stefan Monnier @ 2011-07-04 17:42 UTC (permalink / raw) To: 8680; +Cc: Adrian Robert reassign 8680 emacs,ns tags 8680 +patch thanks Could someone familiar with the MacOSX code take a look at this bug report? Stefan >>>>> "Michael" == Michael Marchionna <tralfaz@pacbell.net> writes: > Adding keypad keycodes to the existing translation table leads to some keys > being wrongly interpreted as keypad keys. To avoid that, this patch > uses a separate translation table exclusively for keys that > generate a NSNumericPadKeyMask. > diff --git a/src/nsterm.m b/src/nsterm.m > index 91f0cbb..d537ee3 100644 > --- a/src/nsterm.m > +++ b/src/nsterm.m > @@ -87,6 +87,7 @@ static unsigned convert_ns_to_X_keysym[] = > NSBeginFunctionKey, 0x58, > NSSelectFunctionKey, 0x60, > NSPrintFunctionKey, 0x61, > + NSClearLineFunctionKey, 0x0B, > NSExecuteFunctionKey, 0x62, > NSInsertFunctionKey, 0x63, > NSUndoFunctionKey, 0x65, > @@ -134,6 +135,35 @@ static unsigned convert_ns_to_X_keysym[] = > 0x1B, 0x1B /* escape */ > }; > +static unsigned convert_nskeypad_to_X_keysym[] = > +{ > + /* Arrow keys are both function and keypad keys */ > + NSLeftArrowFunctionKey, 0x51, > + NSUpArrowFunctionKey, 0x52, > + NSRightArrowFunctionKey, 0x53, > + NSDownArrowFunctionKey, 0x54, > + > + 0x41, 0xAE, /* KP_Decimal */ > + 0x43, 0xAA, /* KP_Multiply */ > + 0x45, 0xAB, /* KP_Add */ > + 0x4B, 0xAF, /* KP_Divide */ > + 0x4E, 0xAD, /* KP_Subtract */ > + 0x51, 0xBD, /* KP_Equal */ > + 0x52, 0xB0, /* KP_0 */ > + 0x53, 0xB1, /* KP_1 */ > + 0x54, 0xB2, /* KP_2 */ > + 0x55, 0xB3, /* KP_3 */ > + 0x56, 0xB4, /* KP_4 */ > + 0x57, 0xB5, /* KP_5 */ > + 0x58, 0xB6, /* KP_6 */ > + 0x59, 0xB7, /* KP_7 */ > + 0x5B, 0xB8, /* KP_8 */ > + 0x5C, 0xB9, /* KP_9 */ > + > + // The enter key is on the keypad but modifier isnt set > + NSEnterCharacter, 0x8D > +}; > + > static Lisp_Object Qmodifier_value; > Lisp_Object Qalt, Qcontrol, Qhyper, Qmeta, Qsuper, Qnone; > @@ -1924,13 +1954,33 @@ ns_convert_key (unsigned code) > unsigned keysym; > /* An array would be faster, but less easy to read. */ > for (keysym = 0; keysym < last_keysym; keysym += 2) > - if (code == convert_ns_to_X_keysym[keysym]) > - return 0xFF00 | convert_ns_to_X_keysym[keysym+1]; > + > + if (code == convert_ns_to_X_keysym[keysym]) { > + return 0xFF00 | convert_ns_to_X_keysym[keysym+1]; > + } > return 0; > /* if decide to use keyCode and Carbon table, use this line: > return code > 0xff ? 0 : 0xFF00 | ns_keycode_to_xkeysym_table[code]; */ > } > +static unsigned > +ns_convert_keypad (unsigned code) > +/* -------------------------------------------------------------------------- > + Internal call used by NSView-keyDown. > + -------------------------------------------------------------------------- */ > +{ > + const unsigned last_keysym = (sizeof (convert_nskeypad_to_X_keysym) > + / sizeof (convert_nskeypad_to_X_keysym[0])); > + unsigned keysym; > + /* An array would be faster, but less easy to read. */ > + for (keysym = 0; keysym < last_keysym; keysym += 2) { > + if (code == convert_nskeypad_to_X_keysym[keysym]) { > + return 0xFF00 | convert_nskeypad_to_X_keysym[keysym+1]; > + } > + } > + return 0; > +} > + > char * > x_get_keysym_name (int keysym) > @@ -4503,10 +4553,10 @@ ns_term_shutdown (int sig) > Mouse_HLInfo *hlinfo = MOUSE_HL_INFO (emacsframe); > int code; > unsigned fnKeysym = 0; > - int flags; > static NSMutableArray *nsEvArray; > static BOOL firstTime = YES; > int left_is_none; > + unsigned int flags = [theEvent modifierFlags]; > NSTRACE (keyDown); > @@ -4550,9 +4600,13 @@ ns_term_shutdown (int sig) > code = ([[theEvent charactersIgnoringModifiers] length] == 0) ? > 0 : [[theEvent charactersIgnoringModifiers] characterAtIndex: 0]; > /* (Carbon way: [theEvent keyCode]) */ > + > /* is it a "function key"? */ > - fnKeysym = ns_convert_key (code); > + if (code < 0x00ff && (flags & NSNumericPadKeyMask) ) > + fnKeysym = ns_convert_keypad([theEvent keyCode]); > + else > + fnKeysym = ns_convert_key(code); > if (fnKeysym) > { > /* COUNTERHACK: map 'Delete' on upper-right main KB to 'Backspace', > @@ -4565,7 +4619,6 @@ ns_term_shutdown (int sig) > /* are there modifiers? */ emacs_event-> modifiers = 0; > - flags = [theEvent modifierFlags]; > if (flags & NSHelpKeyMask) emacs_event-> modifiers |= hyper_modifier; ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#8680: emacs 24.0 OS X keypad patch 2011-07-04 17:42 ` Stefan Monnier @ 2011-07-07 3:04 ` Adrian Robert 2011-07-07 14:55 ` Michael Marchionna 0 siblings, 1 reply; 16+ messages in thread From: Adrian Robert @ 2011-07-07 3:04 UTC (permalink / raw) To: Stefan Monnier; +Cc: 8680, tralfaz The code looks reasonable, but could the author explain why [theEvent keyCode] needs to be used in the keypad conversion instead of code? The code would be more understandable if ns_convert_kaypad() and ns_convert_key() used the same argument. Also this patch should be tested for correct behavior wrt this issue: http://www.cocoabuilder.com/archive/cocoa/73306-workaround-for-broken-numlock-support.html#73306 thanks, Adrian On 2011/07/04, at 13:42, Stefan Monnier wrote: > reassign 8680 emacs,ns > tags 8680 +patch > thanks > > Could someone familiar with the MacOSX code take a look at this > bug report? > > > Stefan > > >>>>>> "Michael" == Michael Marchionna <tralfaz@pacbell.net> writes: > >> Adding keypad keycodes to the existing translation table leads to some keys >> being wrongly interpreted as keypad keys. To avoid that, this patch >> uses a separate translation table exclusively for keys that >> generate a NSNumericPadKeyMask. > > >> diff --git a/src/nsterm.m b/src/nsterm.m >> index 91f0cbb..d537ee3 100644 >> --- a/src/nsterm.m >> +++ b/src/nsterm.m >> @@ -87,6 +87,7 @@ static unsigned convert_ns_to_X_keysym[] = >> NSBeginFunctionKey, 0x58, >> NSSelectFunctionKey, 0x60, >> NSPrintFunctionKey, 0x61, >> + NSClearLineFunctionKey, 0x0B, >> NSExecuteFunctionKey, 0x62, >> NSInsertFunctionKey, 0x63, >> NSUndoFunctionKey, 0x65, >> @@ -134,6 +135,35 @@ static unsigned convert_ns_to_X_keysym[] = >> 0x1B, 0x1B /* escape */ >> }; > >> +static unsigned convert_nskeypad_to_X_keysym[] = >> +{ >> + /* Arrow keys are both function and keypad keys */ >> + NSLeftArrowFunctionKey, 0x51, >> + NSUpArrowFunctionKey, 0x52, >> + NSRightArrowFunctionKey, 0x53, >> + NSDownArrowFunctionKey, 0x54, >> + >> + 0x41, 0xAE, /* KP_Decimal */ >> + 0x43, 0xAA, /* KP_Multiply */ >> + 0x45, 0xAB, /* KP_Add */ >> + 0x4B, 0xAF, /* KP_Divide */ >> + 0x4E, 0xAD, /* KP_Subtract */ >> + 0x51, 0xBD, /* KP_Equal */ >> + 0x52, 0xB0, /* KP_0 */ >> + 0x53, 0xB1, /* KP_1 */ >> + 0x54, 0xB2, /* KP_2 */ >> + 0x55, 0xB3, /* KP_3 */ >> + 0x56, 0xB4, /* KP_4 */ >> + 0x57, 0xB5, /* KP_5 */ >> + 0x58, 0xB6, /* KP_6 */ >> + 0x59, 0xB7, /* KP_7 */ >> + 0x5B, 0xB8, /* KP_8 */ >> + 0x5C, 0xB9, /* KP_9 */ >> + >> + // The enter key is on the keypad but modifier isnt set >> + NSEnterCharacter, 0x8D >> +}; >> + > >> static Lisp_Object Qmodifier_value; >> Lisp_Object Qalt, Qcontrol, Qhyper, Qmeta, Qsuper, Qnone; >> @@ -1924,13 +1954,33 @@ ns_convert_key (unsigned code) >> unsigned keysym; >> /* An array would be faster, but less easy to read. */ >> for (keysym = 0; keysym < last_keysym; keysym += 2) >> - if (code == convert_ns_to_X_keysym[keysym]) >> - return 0xFF00 | convert_ns_to_X_keysym[keysym+1]; >> + >> + if (code == convert_ns_to_X_keysym[keysym]) { >> + return 0xFF00 | convert_ns_to_X_keysym[keysym+1]; >> + } >> return 0; >> /* if decide to use keyCode and Carbon table, use this line: >> return code > 0xff ? 0 : 0xFF00 | ns_keycode_to_xkeysym_table[code]; */ >> } > >> +static unsigned >> +ns_convert_keypad (unsigned code) >> +/* -------------------------------------------------------------------------- >> + Internal call used by NSView-keyDown. >> + -------------------------------------------------------------------------- */ >> +{ >> + const unsigned last_keysym = (sizeof (convert_nskeypad_to_X_keysym) >> + / sizeof (convert_nskeypad_to_X_keysym[0])); >> + unsigned keysym; >> + /* An array would be faster, but less easy to read. */ >> + for (keysym = 0; keysym < last_keysym; keysym += 2) { >> + if (code == convert_nskeypad_to_X_keysym[keysym]) { >> + return 0xFF00 | convert_nskeypad_to_X_keysym[keysym+1]; >> + } >> + } >> + return 0; >> +} >> + > >> char * >> x_get_keysym_name (int keysym) >> @@ -4503,10 +4553,10 @@ ns_term_shutdown (int sig) >> Mouse_HLInfo *hlinfo = MOUSE_HL_INFO (emacsframe); >> int code; >> unsigned fnKeysym = 0; >> - int flags; >> static NSMutableArray *nsEvArray; >> static BOOL firstTime = YES; >> int left_is_none; >> + unsigned int flags = [theEvent modifierFlags]; > >> NSTRACE (keyDown); > >> @@ -4550,9 +4600,13 @@ ns_term_shutdown (int sig) >> code = ([[theEvent charactersIgnoringModifiers] length] == 0) ? >> 0 : [[theEvent charactersIgnoringModifiers] characterAtIndex: 0]; >> /* (Carbon way: [theEvent keyCode]) */ >> + > >> /* is it a "function key"? */ >> - fnKeysym = ns_convert_key (code); >> + if (code < 0x00ff && (flags & NSNumericPadKeyMask) ) >> + fnKeysym = ns_convert_keypad([theEvent keyCode]); >> + else >> + fnKeysym = ns_convert_key(code); >> if (fnKeysym) >> { >> /* COUNTERHACK: map 'Delete' on upper-right main KB to 'Backspace', >> @@ -4565,7 +4619,6 @@ ns_term_shutdown (int sig) > >> /* are there modifiers? */ > emacs_event-> modifiers = 0; >> - flags = [theEvent modifierFlags]; > >> if (flags & NSHelpKeyMask) > emacs_event-> modifiers |= hyper_modifier; ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#8680: emacs 24.0 OS X keypad patch 2011-07-07 3:04 ` Adrian Robert @ 2011-07-07 14:55 ` Michael Marchionna 0 siblings, 0 replies; 16+ messages in thread From: Michael Marchionna @ 2011-07-07 14:55 UTC (permalink / raw) To: Adrian Robert; +Cc: 8680 The reason for split between non-keypad keys and keypad keys, was that the code generated by the following code produced coincident values that produced non-unique results. code = ([[theEvent charactersIgnoringModifiers] length] == 0) ? 0 : [[theEvent charactersIgnoringModifiers] characterAtIndex: 0]; Using the first character of key event would not distinguish a "=" on the main keyboard from a "=" on the keypad. Using the [theEvent keyCode] in the older ns_convert_key function would mean verifying and possibly altering all the translation values in the older table. It may be the case that this change does not properly toggle between numeric keypad, and movement keypad, but on newer mac keyboards the num-lock key is actually a "Clear" key, and Num-Lock behavior is synthesized. Not sure what the best solution for making the "Clear" key behave like a physical Num-Lock key is, but this change does allow key event from the keypad to at least be mapped to something. Michael Marchionna On Jul 6, 2011, at 8:04 PM, Adrian Robert wrote: > The code looks reasonable, but could the author explain why [theEvent keyCode] needs to be used in the keypad conversion instead of code? The code would be more understandable if ns_convert_kaypad() and ns_convert_key() used the same argument. Also this patch should be tested for correct behavior wrt this issue: > > http://www.cocoabuilder.com/archive/cocoa/73306-workaround-for-broken-numlock-support.html#73306 > > > thanks, > Adrian > > > On 2011/07/04, at 13:42, Stefan Monnier wrote: > >> reassign 8680 emacs,ns >> tags 8680 +patch >> thanks >> >> Could someone familiar with the MacOSX code take a look at this >> bug report? >> >> >> Stefan >> >> >>>>>>> "Michael" == Michael Marchionna <tralfaz@pacbell.net> writes: >> >>> Adding keypad keycodes to the existing translation table leads to some keys >>> being wrongly interpreted as keypad keys. To avoid that, this patch >>> uses a separate translation table exclusively for keys that >>> generate a NSNumericPadKeyMask. >> >> >>> diff --git a/src/nsterm.m b/src/nsterm.m >>> index 91f0cbb..d537ee3 100644 >>> --- a/src/nsterm.m >>> +++ b/src/nsterm.m >>> @@ -87,6 +87,7 @@ static unsigned convert_ns_to_X_keysym[] = >>> NSBeginFunctionKey, 0x58, >>> NSSelectFunctionKey, 0x60, >>> NSPrintFunctionKey, 0x61, >>> + NSClearLineFunctionKey, 0x0B, >>> NSExecuteFunctionKey, 0x62, >>> NSInsertFunctionKey, 0x63, >>> NSUndoFunctionKey, 0x65, >>> @@ -134,6 +135,35 @@ static unsigned convert_ns_to_X_keysym[] = >>> 0x1B, 0x1B /* escape */ >>> }; >> >>> +static unsigned convert_nskeypad_to_X_keysym[] = >>> +{ >>> + /* Arrow keys are both function and keypad keys */ >>> + NSLeftArrowFunctionKey, 0x51, >>> + NSUpArrowFunctionKey, 0x52, >>> + NSRightArrowFunctionKey, 0x53, >>> + NSDownArrowFunctionKey, 0x54, >>> + >>> + 0x41, 0xAE, /* KP_Decimal */ >>> + 0x43, 0xAA, /* KP_Multiply */ >>> + 0x45, 0xAB, /* KP_Add */ >>> + 0x4B, 0xAF, /* KP_Divide */ >>> + 0x4E, 0xAD, /* KP_Subtract */ >>> + 0x51, 0xBD, /* KP_Equal */ >>> + 0x52, 0xB0, /* KP_0 */ >>> + 0x53, 0xB1, /* KP_1 */ >>> + 0x54, 0xB2, /* KP_2 */ >>> + 0x55, 0xB3, /* KP_3 */ >>> + 0x56, 0xB4, /* KP_4 */ >>> + 0x57, 0xB5, /* KP_5 */ >>> + 0x58, 0xB6, /* KP_6 */ >>> + 0x59, 0xB7, /* KP_7 */ >>> + 0x5B, 0xB8, /* KP_8 */ >>> + 0x5C, 0xB9, /* KP_9 */ >>> + >>> + // The enter key is on the keypad but modifier isnt set >>> + NSEnterCharacter, 0x8D >>> +}; >>> + >> >>> static Lisp_Object Qmodifier_value; >>> Lisp_Object Qalt, Qcontrol, Qhyper, Qmeta, Qsuper, Qnone; >>> @@ -1924,13 +1954,33 @@ ns_convert_key (unsigned code) >>> unsigned keysym; >>> /* An array would be faster, but less easy to read. */ >>> for (keysym = 0; keysym < last_keysym; keysym += 2) >>> - if (code == convert_ns_to_X_keysym[keysym]) >>> - return 0xFF00 | convert_ns_to_X_keysym[keysym+1]; >>> + >>> + if (code == convert_ns_to_X_keysym[keysym]) { >>> + return 0xFF00 | convert_ns_to_X_keysym[keysym+1]; >>> + } >>> return 0; >>> /* if decide to use keyCode and Carbon table, use this line: >>> return code > 0xff ? 0 : 0xFF00 | ns_keycode_to_xkeysym_table[code]; */ >>> } >> >>> +static unsigned >>> +ns_convert_keypad (unsigned code) >>> +/* -------------------------------------------------------------------------- >>> + Internal call used by NSView-keyDown. >>> + -------------------------------------------------------------------------- */ >>> +{ >>> + const unsigned last_keysym = (sizeof (convert_nskeypad_to_X_keysym) >>> + / sizeof (convert_nskeypad_to_X_keysym[0])); >>> + unsigned keysym; >>> + /* An array would be faster, but less easy to read. */ >>> + for (keysym = 0; keysym < last_keysym; keysym += 2) { >>> + if (code == convert_nskeypad_to_X_keysym[keysym]) { >>> + return 0xFF00 | convert_nskeypad_to_X_keysym[keysym+1]; >>> + } >>> + } >>> + return 0; >>> +} >>> + >> >>> char * >>> x_get_keysym_name (int keysym) >>> @@ -4503,10 +4553,10 @@ ns_term_shutdown (int sig) >>> Mouse_HLInfo *hlinfo = MOUSE_HL_INFO (emacsframe); >>> int code; >>> unsigned fnKeysym = 0; >>> - int flags; >>> static NSMutableArray *nsEvArray; >>> static BOOL firstTime = YES; >>> int left_is_none; >>> + unsigned int flags = [theEvent modifierFlags]; >> >>> NSTRACE (keyDown); >> >>> @@ -4550,9 +4600,13 @@ ns_term_shutdown (int sig) >>> code = ([[theEvent charactersIgnoringModifiers] length] == 0) ? >>> 0 : [[theEvent charactersIgnoringModifiers] characterAtIndex: 0]; >>> /* (Carbon way: [theEvent keyCode]) */ >>> + >> >>> /* is it a "function key"? */ >>> - fnKeysym = ns_convert_key (code); >>> + if (code < 0x00ff && (flags & NSNumericPadKeyMask) ) >>> + fnKeysym = ns_convert_keypad([theEvent keyCode]); >>> + else >>> + fnKeysym = ns_convert_key(code); >>> if (fnKeysym) >>> { >>> /* COUNTERHACK: map 'Delete' on upper-right main KB to 'Backspace', >>> @@ -4565,7 +4619,6 @@ ns_term_shutdown (int sig) >> >>> /* are there modifiers? */ >> emacs_event-> modifiers = 0; >>> - flags = [theEvent modifierFlags]; >> >>> if (flags & NSHelpKeyMask) >> emacs_event-> modifiers |= hyper_modifier; > ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#8680: Bug #8680 2011-05-17 5:07 bug#8680: Cocoa Emacs not mapping Clear key on aluminum keyboards Michael Marchionna 2011-05-17 17:34 ` bug#8680: nsterm.m does not distinguish key on the key pad Michael Marchionna 2011-05-23 20:11 ` bug#8680: emacs 24.0 OS X keypad patch Michael Marchionna @ 2013-12-10 22:13 ` Andrew Stein 2013-12-10 22:40 ` bug#8680: Glenn Morris 2 siblings, 1 reply; 16+ messages in thread From: Andrew Stein @ 2013-12-10 22:13 UTC (permalink / raw) To: 8680 [-- Attachment #1: Type: text/plain, Size: 861 bytes --] I am inquiring about gnu emacs bug #8680. I apologize if I am not using the correct channels. According to the bug report at http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8680 you closed this bug in November 2012 by fixing it by committing the patch to trunk. (Actually there are two patches.) My problem is that I cannot see the effect of this fix in the version of emacs that I am using, namely 24.3.1 from http://emacsformacosx.com/, built in March of 2013. Also when I browse the source at http://git.savannah.gnu.org/cgit/emacs.git/tree/src/nsterm.m?h=emacs-24 I cannot see either patch. Perhaps I am using a wrong version of emacs. If not, could you verify that the patches made it into emacs 24. BTW, there is more info out in Stack Overflow: http://stackoverflow.com/questions/5739974/binding-numeric-keypad-keys-with-emacs-24-and-os-x Andrew Stein [-- Attachment #2: Type: text/html, Size: 1923 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#8680: 2013-12-10 22:13 ` bug#8680: Bug #8680 Andrew Stein @ 2013-12-10 22:40 ` Glenn Morris 2013-12-10 22:54 ` bug#8680: Andrew Stein 0 siblings, 1 reply; 16+ messages in thread From: Glenn Morris @ 2013-12-10 22:40 UTC (permalink / raw) To: Andrew Stein; +Cc: 8680 The patch is in the Emacs trunk, not the emacs-24 branch, which means it will first appear in Emacs 24.4 when it comes out. It was not in 24.3. (I've previously encourage people to include the fixed version when they close bugs, but many still do not.) ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#8680: 2013-12-10 22:40 ` bug#8680: Glenn Morris @ 2013-12-10 22:54 ` Andrew Stein 2013-12-11 4:53 ` bug#8680: Stefan Monnier 0 siblings, 1 reply; 16+ messages in thread From: Andrew Stein @ 2013-12-10 22:54 UTC (permalink / raw) To: Glenn Morris; +Cc: 8680 [-- Attachment #1: Type: text/plain, Size: 490 bytes --] Hi Glenn, Thank you very much for the quick reply. I guess I will wait for the release of emacs 24.4. When can we expect the happy event? Andrew Stein On Tue, Dec 10, 2013 at 4:40 PM, Glenn Morris <rgm@gnu.org> wrote: > > The patch is in the Emacs trunk, not the emacs-24 branch, which means it > will first appear in Emacs 24.4 when it comes out. It was not in 24.3. > > (I've previously encourage people to include the fixed version when they > close bugs, but many still do not.) > [-- Attachment #2: Type: text/html, Size: 861 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#8680: 2013-12-10 22:54 ` bug#8680: Andrew Stein @ 2013-12-11 4:53 ` Stefan Monnier 2013-12-12 0:48 ` bug#8680: Leo Liu 0 siblings, 1 reply; 16+ messages in thread From: Stefan Monnier @ 2013-12-11 4:53 UTC (permalink / raw) To: Andrew Stein; +Cc: 8680 > Thank you very much for the quick reply. I guess I will wait for the > release of emacs 24.4. When can we expect the happy event? Hopefully before Xmas 2014. Stefan ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#8680: 2013-12-11 4:53 ` bug#8680: Stefan Monnier @ 2013-12-12 0:48 ` Leo Liu 2013-12-13 21:50 ` bug#8680: releases Juri Linkov 0 siblings, 1 reply; 16+ messages in thread From: Leo Liu @ 2013-12-12 0:48 UTC (permalink / raw) To: Stefan Monnier; +Cc: 8680, Andrew Stein On 2013-12-11 12:53 +0800, Stefan Monnier wrote: > Hopefully before Xmas 2014. > > > Stefan How time flies! I wonder if in future we could go a lighter-weight release process i.e. every 3 months. I have been using emacs 24.3 most of the time and it took me some time to absorb all the nice features in 24.4. I think the features that we put efforts to develop would be better received if delivered gradually. Leo ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#8680: releases 2013-12-12 0:48 ` bug#8680: Leo Liu @ 2013-12-13 21:50 ` Juri Linkov 2013-12-19 3:00 ` Leo Liu 0 siblings, 1 reply; 16+ messages in thread From: Juri Linkov @ 2013-12-13 21:50 UTC (permalink / raw) To: Leo Liu; +Cc: 8680, Andrew Stein > I wonder if in future we could go a lighter-weight release process i.e. > every 3 months. Want to catch up on the version numbers with Chrome and Firefox? :-) ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#8680: releases 2013-12-13 21:50 ` bug#8680: releases Juri Linkov @ 2013-12-19 3:00 ` Leo Liu 2013-12-19 13:43 ` Stefan Monnier 0 siblings, 1 reply; 16+ messages in thread From: Leo Liu @ 2013-12-19 3:00 UTC (permalink / raw) To: Juri Linkov; +Cc: 8680 On 2013-12-14 05:50 +0800, Juri Linkov wrote: > Want to catch up on the version numbers with Chrome and Firefox? :-) I mean point releases so we can't catch them. For example, have two or three point releases which isn't too many. Leo ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#8680: releases 2013-12-19 3:00 ` Leo Liu @ 2013-12-19 13:43 ` Stefan Monnier 2013-12-19 17:12 ` Glenn Morris 0 siblings, 1 reply; 16+ messages in thread From: Stefan Monnier @ 2013-12-19 13:43 UTC (permalink / raw) To: Leo Liu; +Cc: 8680 I'm all in favor of more frequent release cycles. Currently we run at about one-release per year, which isn't that bad. I wanted to bring this up to 2 releases per year, but noone had the energy to take care of the release management (basically, the amount of effort involved in a pretest did not seem worthwhile compared to the incremental improvement in features). BTW: since we're about to freeze and start a new pretest phase, we're looking for a volunteer to take care of rolling the pretests. Also, we'd welcome some help to update the manuals (most urgently, to integrate all the changes mentioned in NEWS into the manuals). Stefan ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#8680: releases 2013-12-19 13:43 ` Stefan Monnier @ 2013-12-19 17:12 ` Glenn Morris 0 siblings, 0 replies; 16+ messages in thread From: Glenn Morris @ 2013-12-19 17:12 UTC (permalink / raw) To: Stefan Monnier; +Cc: 8680 (A 2 year-old archived bug about Mac keyboards isn't the best place for this discussion, but I'm not going to bother to move it.) Stefan Monnier wrote: > I wanted to bring this up to 2 releases per year, but noone had the > energy to take care of the release management That's not how I recall it. IIRC, you wanted to freeze 24.4 ~ six weeks after 24.3 was released. This would have left very little time for people who had been concentrating on the release to develop any new features. > BTW: since we're about to freeze and start a new pretest phase, we're > looking for a volunteer to take care of rolling the pretests. Oh, are you? I would have been happy to do it again. But I see Chong Yidong is back (yay!), so if he wants to do it; or if someone else wants to have a go, it's fine by me. > Also, we'd welcome some help to update the manuals (most urgently, to > integrate all the changes mentioned in NEWS into the manuals). That, of course, is the hard part. Traditionally this large burden has fallen on a tiny number of people. If suddenly lots of people are going to start doing this, of course you can crank out more frequent releases. ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2013-12-19 17:12 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-05-17 5:07 bug#8680: Cocoa Emacs not mapping Clear key on aluminum keyboards Michael Marchionna 2011-05-17 17:34 ` bug#8680: nsterm.m does not distinguish key on the key pad Michael Marchionna 2012-11-04 3:34 ` Chong Yidong 2011-05-23 20:11 ` bug#8680: emacs 24.0 OS X keypad patch Michael Marchionna 2011-07-04 17:42 ` Stefan Monnier 2011-07-07 3:04 ` Adrian Robert 2011-07-07 14:55 ` Michael Marchionna 2013-12-10 22:13 ` bug#8680: Bug #8680 Andrew Stein 2013-12-10 22:40 ` bug#8680: Glenn Morris 2013-12-10 22:54 ` bug#8680: Andrew Stein 2013-12-11 4:53 ` bug#8680: Stefan Monnier 2013-12-12 0:48 ` bug#8680: Leo Liu 2013-12-13 21:50 ` bug#8680: releases Juri Linkov 2013-12-19 3:00 ` Leo Liu 2013-12-19 13:43 ` Stefan Monnier 2013-12-19 17:12 ` Glenn Morris
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).