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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Anders Lindgren <andlind <at> gmail.com>
Subject: bug#16505: closed (Re: bug#16505: Acknowledgement (24.3.50; Emacs
 seems to loose key events when typing fast (seriously)))
Date: Sun, 16 Feb 2014 09:53:02 +0000

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

Your bug report

#16505: 24.3.50; Emacs seems to lose key events when typing fast

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 16505 <at> debbugs.gnu.org.

-- 
16505: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16505
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

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

[Message part 3 (message/rfc822, inline)]

From: Anders Lindgren <andlind <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; Emacs seems to loose key events when typing fast (seriously)
Date: Mon, 20 Jan 2014 16:25:15 +0100

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

When typing something fast like <down> <tab> repeated over and over again,
Emacs seems to loose key events. This seems to work correctly on 23.3.

Steps to repeat:

    emacs -Q
    Evaluate:

    (progn (insert "(") (make-string



In GNU Emacs 24.3.50.4 (x86_64-apple-darwin13.0.0, NS apple-appkit-1265.00)
 of 2014-01-16 on macpro.lan
Repository revision: 116039
eggert <at> cs.ucla.edu-20140116062406-oh0d3tsfqytj28ta
Windowing system distributor `Apple', version 10.3.1265
Configured using:
 `configure --with-ns'

Important settings:
  value of $LC_CTYPE: UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<escape> x r e p o <tab> r <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
help-fns mail-prsvr mail-utils help-mode easymenu time-date tooltip
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel ns-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
cocoa ns multi-tty emacs)

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

Previous Next

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