bug#8680: Cocoa Emacs not mapping Clear key on aluminum keyboards.

bug#8680: Cocoa Emacs not mapping Clear key on aluminum keyboards.

[Michael Marchionna]

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.

bug#8680: nsterm.m does not distinguish key on the key pad

[Michael Marchionna]

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;

bug#8680: emacs 24.0 OS X keypad patch

[Michael Marchionna]

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

bug#8680: emacs 24.0 OS X keypad patch

[Stefan Monnier]

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;

bug#8680: emacs 24.0 OS X keypad patch

[Adrian Robert]

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;

bug#8680: emacs 24.0 OS X keypad patch

[Michael Marchionna]

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

bug#8680: nsterm.m does not distinguish key on the key pad

[Chong Yidong]

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.

bug#8680: Bug #8680

[Andrew Stein]

[-- 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 --]

bug#8680:

[Glenn Morris]

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

bug#8680:

[Andrew Stein]

[-- 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 --]

bug#8680:

[Stefan Monnier]

> 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

bug#8680:

[Leo Liu]

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

bug#8680: releases

[Juri Linkov]

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

bug#8680: releases

[Leo Liu]

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

bug#8680: releases

[Stefan Monnier]

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

bug#8680: releases

[Glenn Morris]

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

The next releases

[Stefan Monnier]

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

Oops, indeed, thanks for staying alert.

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

I might indeed be looking at the past through those funny lenses.

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

Very much so, yes.

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

Not sure if Yidong is volunteering, but in any case I'm very happy to
see him back as well.

But to tell you the truth, I'd welcome newer blood to roll
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).
> 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.

I wish I knew the magic recipe to get people working on it.


        Stefan

Re: The next releases

[Stefan Monnier]

> But to tell you the truth, I'd welcome newer blood to roll
> the pretests.

Sean Sieger has volunteered to roll the pretests, and I thank him for that.

So now we only need a dozen volunteers to update the manuals.  Any takers?


        Stefan

Re: The next releases

[Bastien]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> So now we only need a dozen volunteers to update the manuals.  Any
> takers?

I'm in.  Are there specific bugs related to that?
Or is there any direction somewhere?

Thanks!

-- 
 Bastien

Re: The next releases

[Stefan Monnier]

>> So now we only need a dozen volunteers to update the manuals.  Any
>> takers?
> I'm in.  Are there specific bugs related to that?
> Or is there any direction somewhere?

Read the etc/NEWS file.   All entries for "24.4" correspond to changes
which should be reflected in the manuals.  Those for which the manual
has been updated are (or should be) marked with a "+++" or a "---" as
explained at the beginning of the NEWS file.  All others need work
(sometimes, there's nothing to change in the manual, but someone needs
to check, and after checking, she should add the +++ or ---).


        Stefan

Re: The next releases

[Chong Yidong]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> 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.
>
> Not sure if Yidong is volunteering, but in any case I'm very happy to
> see him back as well.

Thanks.  I am back in the capacity of an ordinary contributor.
Unfortunately, I will not have time to roll the pretests or help with
other aspects of the release management process.  But I will help work
on the manuals.

Re: The next releases

[Xue Fuqiao]

On Fri, Dec 20, 2013 at 5:22 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> But to tell you the truth, I'd welcome newer blood to roll
>> the pretests.
>
> Sean Sieger has volunteered to roll the pretests, and I thank him for that.
>
> So now we only need a dozen volunteers to update the manuals.  Any takers?

I'm in.

-- 
http://www.gnu.org/software/emacs/

Re: The next releases

[Glenn Morris]

Great to see people helping out with the docs.
If you want people to check what you've done, not adding the +++ marks
to the NEWS file should ensure that someone else looks at it too.

Re: The next releases

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 360 bytes --]

On Sun, 22 Dec 2013 19:57:55 -0500 Glenn Morris <rgm@gnu.org> wrote: 

GM> Great to see people helping out with the docs.
GM> If you want people to check what you've done, not adding the +++ marks
GM> to the NEWS file should ensure that someone else looks at it too.

I'm not good with NEWS formatting and content; can you review the patch
below?

Thanks
Ted


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: tzz-news-24.4.patch --]
[-- Type: text/x-diff, Size: 2333 bytes --]

=== modified file 'etc/NEWS'
--- etc/NEWS	2013-12-22 23:19:42 +0000
+++ etc/NEWS	2013-12-23 01:36:17 +0000
@@ -23,6 +23,9 @@
 \f
 * Installation Changes in Emacs 24.4
 
+---
+** Emacs now detects and uses GnuTLS v3 features
+
 ** Emacs can now be compiled with ACL support.
 This happens by default if a suitable support library is found at
 build time, like libacl on GNU/Linux.  To prevent this, use the
@@ -91,6 +94,12 @@
 * Changes in Emacs 24.4
 
 +++
+** Emacs can now reject invalid SSL/TLS certificates, as determined by
+GnuTLS The new variable `gnutls-verify-error' can be customized.  It
+is off for now, but will be turned to reject invalid certificates by
+default in the future.
+
++++
 ** Emacs now supports menus on text-mode terminals.
 If the terminal supports a mouse, clicking on the menu bar, or on
 sensitive portions of the mode line or header line, will drop down the
@@ -393,6 +402,14 @@
 
 *** CUA's rectangles can now be used via `cua-rectangle-mark-mode'.
 
+** CFEngine mode
+
+*** CFEngine mode has completion and ElDoc support
+
+*** CFEngine mode can parse the current syntax from cf-promises
+
+*** CFEngine mode has Flycheck support for on-the-fly syntax checking
+
 ** Delete Selection mode can now be used without `transient-mark-mode'.
 
 ** Desktop
@@ -561,6 +578,17 @@
 *** `describe-package' buffer uses the `:url' extra property to
 display a `Homepage' header, if it's present.
 
++++
+*** `describe-package' buffer uses the `:keywords extra property to
+display keyword buttons.  Clicking them shows the list of packages
+that have that keyword.
+
++++
+*** the list of packages now shows the archive
+
++++
+*** the list of packages can now be filtered by a keyword
+
 ** Prolog mode
 
 *** `prolog-use-smie' has been removed, along with the non-SMIE

=== modified file 'lisp/progmodes/cfengine.el'
--- lisp/progmodes/cfengine.el	2013-12-16 15:49:25 +0000
+++ lisp/progmodes/cfengine.el	2013-12-23 01:01:31 +0000
@@ -1322,9 +1322,6 @@
           nil nil nil beginning-of-defun))
   (setq-local prettify-symbols-alist cfengine3--prettify-symbols-alist)
 
-  ;; `compile-command' is almost never a `make' call with CFEngine so
-  ;; we override it
-  (when cfengine-cf-promises
     (set (make-local-variable 'compile-command)
          (concat cfengine-cf-promises
                  " -f "

Re: The next releases

[Glenn Morris]

My general comment is: never hesitate to make a NEWS entry.
Not giving it any +++/--- markup means someone will check it.

Ted Zlatanov wrote:

> +---
> +** Emacs now detects and uses GnuTLS v3 features

Quibbling about language, but I'd say something like:

  ** Emacs now uses GnuTLS v3 features where available.

But as a user, this tells me nothing, so I'm not sure I see the point of
this entry as it stands.

>  +++
> +** Emacs can now reject invalid SSL/TLS certificates, as determined by
> +GnuTLS The new variable `gnutls-verify-error' can be customized.  It
> +is off for now, but will be turned to reject invalid certificates by
> +default in the future.

[If this is a new option, it should have a :version tag.]

** New option `gnutls-verify-error', if non-nil, means that Emacs
should reject SSL/TLS certificates that GnuTLS determines as invalid.  
(This option defaults to nil at present, but this is expected to change
in a future release.)

> +
> ++++
>  ** Emacs now supports menus on text-mode terminals.

Did you mean to add that markup? It seems an unrelated change.

> +** CFEngine mode

It seems redundant to say "CFEngine mode..." in all the following, given
that the whole section is about CFEngine mode.

> +
> +*** CFEngine mode has completion and ElDoc support
[...]
> +*** CFEngine mode has Flycheck support for on-the-fly syntax checking

*** Support for completion, ElDoc, and Flycheck has been added.

> +*** CFEngine mode can parse the current syntax from cf-promises

I have no idea what that means, but I'm not a CFEngine user, so that may
be expected.

> ++++
> +*** `describe-package' buffer uses the `:keywords extra property to
> +display keyword buttons.  Clicking them shows the list of packages
> +that have that keyword.

*** In the buffer produced by `describe-package', there are now buttons
listing the keywords related to that package.  You can click on them
to see other packages related to any given keyword.

> ++++
> +*** the list of packages now shows the archive

*** The output of `list-packages' now includes the archive providing
each package.

[Though this will be self-evident, so I'm not sure it is worth
mentioning.]

> ++++
> +*** the list of packages can now be filtered by a keyword

I don't understand what this really means. The wording makes me think
it's somehow related to the list-packages command, but it does not seem
to be.


Second general comment is that NEWS entries should be grammatical: start
with a capital, end with a full-stop.

Re: The next releases

[Glenn Morris]

Glenn Morris wrote:

>> ++++
>>  ** Emacs now supports menus on text-mode terminals.
>
> Did you mean to add that markup? It seems an unrelated change.

That was just me misreading the diff.

Although, that means you're saying gnutls-verify-error is documented,
and I can't see that it is.

Re: The next releases

[Ted Zlatanov]

On Sun, 22 Dec 2013 22:11:43 -0500 Glenn Morris <rgm@gnu.org> wrote: 

GM> Quibbling about language, but I'd say something like:

GM>   ** Emacs now uses GnuTLS v3 features where available.

GM> But as a user, this tells me nothing, so I'm not sure I see the point of
GM> this entry as it stands.

OK; removed.

>> +++
>> +** Emacs can now reject invalid SSL/TLS certificates, as determined by
>> +GnuTLS The new variable `gnutls-verify-error' can be customized.  It
>> +is off for now, but will be turned to reject invalid certificates by
>> +default in the future.

GM> [If this is a new option, it should have a :version tag.]

GM> ** New option `gnutls-verify-error', if non-nil, means that Emacs
GM> should reject SSL/TLS certificates that GnuTLS determines as invalid.  
GM> (This option defaults to nil at present, but this is expected to change
GM> in a future release.)

Thanks, used this.

GM> Although, that means you're saying gnutls-verify-error is documented,
GM> and I can't see that it is.

Right, fixed.

>> +** CFEngine mode

GM> It seems redundant to say "CFEngine mode..." in all the following, given
GM> that the whole section is about CFEngine mode.

I was following the pattern above:

#+begin_src text
** CUA mode

*** CUA mode was changed to make use of delete-selection-mode and
#+end_src

I fixed up the CFEngine-related and package.el things.

>> ++++
>> +*** the list of packages now shows the archive

GM> *** The output of `list-packages' now includes the archive providing
GM> each package.

GM> [Though this will be self-evident, so I'm not sure it is worth
GM> mentioning.]

OK, omitted.

>> +*** the list of packages can now be filtered by a keyword

GM> I don't understand what this really means. The wording makes me think
GM> it's somehow related to the list-packages command, but it does not seem
GM> to be.

OK, fixed.

GM> Second general comment is that NEWS entries should be grammatical: start
GM> with a capital, end with a full-stop.

Thanks for the review!  I pushed my changes as you suggested and hope
they are OK.

Ted