GNU bug report logs - #16505
24.3.50; Emacs seems to lose key events when typing fast

Previous Next

Full log

Message #48 received at 16505-done <at> debbugs.gnu.org (full text, mbox):

From: "Jan D." <jan.h.d <at> swipnet.se>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: 16505-done <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Dmitry Antipov <dmantipov <at> yandex.ru>, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#16505: Acknowledgement (24.3.50; Emacs seems to loose key
 events when typing fast (seriously))
Date: Sun, 16 Feb 2014 10:52:25 +0100

Anders Lindgren skrev 2014-02-16 08:42:
> Hi!
>

Hello.

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

Checked in, thanks.

	Jan D.

>
> 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.m2014-02-10 22:15:54 +0000
> +++ src/nsterm.m2014-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 <at> gmail.com
> <mailto:andlind <at> 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 <at> pacbell.net
>     <mailto:tralfaz <at> pacbell.net>>
>     committer: Chong Yidong <cyd <at> gnu.org <mailto:cyd <at> 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 <at> gnu.org
>     <mailto:eliz <at> gnu.org>> wrote:
>
>          > Date: Sat, 8 Feb 2014 21:04:13 +0100
>          > From: Anders Lindgren <andlind <at> gmail.com
>         <mailto:andlind <at> gmail.com>>
>          > Cc: Dmitry Antipov <dmantipov <at> yandex.ru
>         <mailto:dmantipov <at> yandex.ru>>, larsi <at> gnus.org
>         <mailto:larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org
>         <mailto:eliz <at> 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.
>
>
>

Previous Next

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