GNU bug report logs - #8680
Cocoa Emacs not mapping Clear key on aluminum keyboards.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8680 in the body.
You can then email your comments to 8680 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Marchionna <tralfaz <at> pacbell.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Cocoa Emacs not mapping Clear key on aluminum keyboards.
Date: Mon, 16 May 2011 22:07:12 -0700

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.

Message #8 received at 8680 <at> debbugs.gnu.org (full text, mbox):

From: Michael Marchionna <tralfaz <at> pacbell.net>
To: 8680 <at> debbugs.gnu.org
Subject: nsterm.m does not distinguish key on the key pad
Date: Tue, 17 May 2011 10:34:01 -0700

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;

Message #11 received at 8680 <at> debbugs.gnu.org (full text, mbox):

From: Michael Marchionna <tralfaz <at> pacbell.net>
To: 8680 <at> debbugs.gnu.org
Subject: emacs 24.0 OS X keypad patch
Date: Mon, 23 May 2011 13:11:43 -0700

[Message part 1 (text/plain, inline)]

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.

[emacs-24-src-nsterm.m.patch (application/octet-stream, attachment)]

Message #14 received at 8680 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: 8680 <at> debbugs.gnu.org
Cc: Adrian Robert <Adrian.B.Robert <at> gmail.com>
Subject: Re: bug#8680: emacs 24.0 OS X keypad patch
Date: Mon, 04 Jul 2011 13:42:57 -0400

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 <at> 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;

Message #17 received at 8680 <at> debbugs.gnu.org (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 8680 <at> debbugs.gnu.org, tralfaz <at> pacbell.net
Subject: Re: bug#8680: emacs 24.0 OS X keypad patch
Date: Wed, 6 Jul 2011 23:04:15 -0400

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 <at> 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;

Message #20 received at 8680 <at> debbugs.gnu.org (full text, mbox):

From: Michael Marchionna <tralfaz <at> pacbell.net>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: 8680 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#8680: emacs 24.0 OS X keypad patch
Date: Thu, 7 Jul 2011 07:55:32 -0700

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 <at> 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;
> 

Message #27 received at 8680 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: Michael Marchionna <tralfaz <at> pacbell.net>
Cc: 8680 <at> debbugs.gnu.org
Subject: Re: bug#8680: nsterm.m does not distinguish key on the key pad
Date: Sun, 04 Nov 2012 11:34:44 +0800

Michael Marchionna <tralfaz <at> 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.

Message #36 received at 8680 <at> debbugs.gnu.org (full text, mbox):

From: Andrew Stein <andrewstein9 <at> gmail.com>
To: 8680 <8680 <at> debbugs.gnu.org>
Subject: Bug #8680
Date: Tue, 10 Dec 2013 16:13:58 -0600

[Message part 1 (text/plain, inline)]

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

[Message part 2 (text/html, inline)]

Message #39 received at 8680 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Andrew Stein <andrewstein9 <at> gmail.com>
Cc: 8680 <at> debbugs.gnu.org
Subject: Re: Bug#8680
Date: Tue, 10 Dec 2013 17:40:28 -0500

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.)

Message #46 received at 8680 <at> debbugs.gnu.org (full text, mbox):

From: Andrew Stein <andrewstein9 <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 8680 <at> debbugs.gnu.org
Subject: Re: Bug#8680
Date: Tue, 10 Dec 2013 16:54:03 -0600

[Message part 1 (text/plain, inline)]

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 <at> 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.)
>

[Message part 2 (text/html, inline)]

Message #49 received at 8680 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Andrew Stein <andrewstein9 <at> gmail.com>
Cc: 8680 <at> debbugs.gnu.org, Glenn Morris <rgm <at> gnu.org>
Subject: Re: bug#8680:
Date: Tue, 10 Dec 2013 23:53:28 -0500

> 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

Message #52 received at 8680 <at> debbugs.gnu.org (full text, mbox):

From: Leo Liu <sdl.web <at> gmail.com>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 8680 <at> debbugs.gnu.org, Andrew Stein <andrewstein9 <at> gmail.com>
Subject: Re: bug#8680:
Date: Thu, 12 Dec 2013 08:48:40 +0800

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

Message #55 received at 8680 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 8680 <at> debbugs.gnu.org, Andrew Stein <andrewstein9 <at> gmail.com>,
 Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: Re: bug#8680: releases
Date: Fri, 13 Dec 2013 23:50:07 +0200

> 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?  :-)

Message #58 received at 8680 <at> debbugs.gnu.org (full text, mbox):

From: Leo Liu <sdl.web <at> gmail.com>
To: Juri Linkov <juri <at> jurta.org>
Cc: 8680 <at> debbugs.gnu.org
Subject: Re: bug#8680: releases
Date: Thu, 19 Dec 2013 11:00:10 +0800

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

Message #61 received at 8680 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: Juri Linkov <juri <at> jurta.org>, 8680 <at> debbugs.gnu.org
Subject: Re: bug#8680: releases
Date: Thu, 19 Dec 2013 08:43:48 -0500

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

Message #64 received at 8680 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 8680 <at> debbugs.gnu.org
Subject: Re: bug#8680: releases
Date: Thu, 19 Dec 2013 12:12:54 -0500

(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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.