Hi!

I got some time to track down the problem. It appears as though the OS
sometimes adds a spurious "key pad" flag to keys not on the key pad. The
way the nsterm.m is implemented, it fails to look them up making the key
dead.

The following patch will first try to lookup the key as a keypad key, and
if that fails, it will look it up as a plain key.

I have talked to the author of the 110793 revision and he has confirmed
that my patch works OK.

Unfortunately, I don't have write access to the bzr archive, so I can't
commit this myself.

=== modified file 'src/nsterm.m'
--- src/nsterm.m 2014-02-10 22:15:54 +0000
+++ src/nsterm.m 2014-02-15 07:01:48 +0000
@@ -5119,9 +5119,17 @@
       /* (Carbon way: [theEvent keyCode]) */

       /* is it a "function key"? */
-      fnKeysym = (code < 0x00ff && (flags&NSNumericPadKeyMask))
- ? ns_convert_key ([theEvent keyCode] | NSNumericPadKeyMask)
- : ns_convert_key (code);
+      /* Note: Sometimes a plain key will have the NSNumericPadKeyMask
+         flag set (this is probably a bug in the OS).
+      */
+      if (code < 0x00ff && (flags&NSNumericPadKeyMask))
+        {
+          fnKeysym = ns_convert_key ([theEvent keyCode] |
NSNumericPadKeyMask);
+        }
+      if (fnKeysym == 0)
+        {
+          fnKeysym = ns_convert_key (code);
+        }

       if (fnKeysym)
         {



Sincerely,
    Anders Lindgren



On Sun, Feb 9, 2014 at 1:56 PM, Anders Lindgren <andlind@gmail.com> wrote:

> Got it! It's revision 110793 -- this is a change to nsterm.m (hence an OS
> X-specific problem).
>
> The bzr log is as follows:
>
> revno: 110793
> fixes bug: http://debbugs.gnu.org/8680
> author: Michael Marchionna <tralfaz@pacbell.net>
> committer: Chong Yidong <cyd@gnu.org>
> branch nick: trunk
> timestamp: Sun 2012-11-04 11:34:10 +0800
> message:
>   * nsterm.m: Add NSClearLineFunctionKey and keypad keys.
>   (keyDown): Remap keypad keys to X11 virtual key codes.
>
> When looking at the code, it's unfortunately not obvious (to me) what the
> cause is...
>
>     -- Anders
>
>
>
> On Sat, Feb 8, 2014 at 9:29 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > Date: Sat, 8 Feb 2014 21:04:13 +0100
>> > From: Anders Lindgren <andlind@gmail.com>
>> > Cc: Dmitry Antipov <dmantipov@yandex.ru>, larsi@gnus.org, Eli
>> Zaretskii <eliz@gnu.org>
>> >
>> > By back-applying 111505 into earlier revisions I have concluded that
>> 110812
>> > contains the problem. To ensure that the problem wasn't caused by 111505
>> > itself, I also applied it to 110785 (the last revision without this
>> > problem) without introducing the "key dropped" problem. In other words,
>> the
>> > problem must have been introduced somewhere in the range 110796..110811.
>>
>> If that is the range, the only relevant commit seems to be 110802.
>>
>> > Unfortunately, I get a build error below for these revisions. The build
>> > error is "not enough room for load commands for new __DATA segments",
>> which
>> > is issued from deep inside the "unexmacosx.c" module. I have no insight
>> > into the "unexec" process, so this has stopped me from narrowing down
>> the
>> > problem further.
>> >
>> > Any suggestions on moving forward would be welcome -- for example,
>> would it
>> > be possible to run Emacs undumped, avoiding unexec all together?
>>
>> Try reverting only 110802.
>>
>
>