* bug#16505: 24.3.50; Emacs seems to loose key events when typing fast (seriously) @ 2014-01-20 15:25 Anders Lindgren [not found] ` <handler.16505.B.139023152917540.ack@debbugs.gnu.org> 0 siblings, 1 reply; 14+ messages in thread From: Anders Lindgren @ 2014-01-20 15:25 UTC (permalink / raw) To: 16505 [-- Attachment #1: Type: text/plain, Size: 2185 bytes --] 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@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) [-- Attachment #2: Type: text/html, Size: 3013 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <handler.16505.B.139023152917540.ack@debbugs.gnu.org>]
* bug#16505: Acknowledgement (24.3.50; Emacs seems to loose key events when typing fast (seriously)) [not found] ` <handler.16505.B.139023152917540.ack@debbugs.gnu.org> @ 2014-01-20 15:36 ` Anders Lindgren 2014-02-07 14:17 ` Anders Lindgren 0 siblings, 1 reply; 14+ messages in thread From: Anders Lindgren @ 2014-01-20 15:36 UTC (permalink / raw) To: 16505 [-- Attachment #1: Type: text/plain, Size: 1534 bytes --] I just sent out the previous letter before it was finished, so here comes the rest of it (sorry about that): Steps to repeat: emacs -Q Evaluate the following: (save-excursion (insert "(") (dotimes (x 10) (insert "abc\n"))) C-g (Just to know where you are in C-h l) Now press TAB and down arrow over and over again, as fast as you can, like you're reindenting code. After a few lines, Emacs stops to indent. Looking at the end of C-h l, you will see something like: C-g <tab> <down> <down> <tab> <down> <tab> <down> <tab> <down> <tab> C-h l Here, a <tab> is missing, which explains the indentation problems. Sincerely, Anders Lindgren On Mon, Jan 20, 2014 at 4:26 PM, GNU bug Tracking System < help-debbugs@gnu.org> wrote: > Thank you for filing a new bug report with debbugs.gnu.org. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > bug-gnu-emacs@gnu.org > > If you wish to submit further information on this problem, please > send it to 16505@debbugs.gnu.org. > > Please do not send mail to help-debbugs@gnu.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 16505: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16505 > GNU Bug Tracking System > Contact help-debbugs@gnu.org with problems > [-- Attachment #2: Type: text/html, Size: 2594 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16505: Acknowledgement (24.3.50; Emacs seems to loose key events when typing fast (seriously)) 2014-01-20 15:36 ` bug#16505: Acknowledgement (24.3.50; Emacs seems to loose key events when typing fast (seriously)) Anders Lindgren @ 2014-02-07 14:17 ` Anders Lindgren 2014-02-07 16:06 ` Dmitry Antipov 0 siblings, 1 reply; 14+ messages in thread From: Anders Lindgren @ 2014-02-07 14:17 UTC (permalink / raw) To: 16505 [-- Attachment #1: Type: text/plain, Size: 2505 bytes --] I have looked a little bit into this (even though I haven't found much). The following are the key bzr revisions: 110785 -- OK 110786..110811 -- Don't build on OS X (error during dump) 110812..111504 -- Broken in another way. When pressing <down> <tab> over an over again, Emacs gets stuck. Neither <tab> nor <down> will do anything. However, typing a plain character makes Emacs escape this state and start being responsive again. This seems to be an OS X related problem, as the fix was applied to nsterm.m. 111505 -- Broken as described in the original posts. I hope this can shed some light on this, as this is a real problem that will affect lots of users. One thing we should try to figure out is if this is a problem specific to OS X, or if it is generic. Sincerely, Anders Lindgren On Mon, Jan 20, 2014 at 4:36 PM, Anders Lindgren <andlind@gmail.com> wrote: > I just sent out the previous letter before it was finished, so here comes > the rest of it (sorry about that): > > Steps to repeat: > > emacs -Q > Evaluate the following: > (save-excursion > (insert "(") > (dotimes (x 10) (insert "abc\n"))) > C-g (Just to know where you are in C-h l) > Now press TAB and down arrow over and over again, as fast as you can, > like you're reindenting code. > After a few lines, Emacs stops to indent. Looking at the end of C-h l, > you will see something like: > > C-g <tab> <down> <down> > <tab> <down> <tab> <down> <tab> <down> <tab> C-h l > > Here, a <tab> is missing, which explains the indentation problems. > > Sincerely, > Anders Lindgren > > > > On Mon, Jan 20, 2014 at 4:26 PM, GNU bug Tracking System < > help-debbugs@gnu.org> wrote: > >> Thank you for filing a new bug report with debbugs.gnu.org. >> >> This is an automatically generated reply to let you know your message >> has been received. >> >> Your message is being forwarded to the package maintainers and other >> interested parties for their attention; they will reply in due course. >> >> Your message has been sent to the package maintainer(s): >> bug-gnu-emacs@gnu.org >> >> If you wish to submit further information on this problem, please >> send it to 16505@debbugs.gnu.org. >> >> Please do not send mail to help-debbugs@gnu.org unless you wish >> to report a problem with the Bug-tracking system. >> >> -- >> 16505: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16505 >> GNU Bug Tracking System >> Contact help-debbugs@gnu.org with problems >> > > [-- Attachment #2: Type: text/html, Size: 4110 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16505: Acknowledgement (24.3.50; Emacs seems to loose key events when typing fast (seriously)) 2014-02-07 14:17 ` Anders Lindgren @ 2014-02-07 16:06 ` Dmitry Antipov 2014-02-07 21:03 ` Anders Lindgren 2014-02-08 0:14 ` Lars Ingebrigtsen 0 siblings, 2 replies; 14+ messages in thread From: Dmitry Antipov @ 2014-02-07 16:06 UTC (permalink / raw) To: Anders Lindgren; +Cc: 16505 On 02/07/2014 06:17 PM, Anders Lindgren wrote: > Here, a <tab> is missing, which explains the indentation problems. Hmm...IMHO we shouldn't believe in anyone's fingers in such a case :-). Do you have a tool to fake user input? On X, we have xdotool. I've tried to insert 100 <tab> and 100 <down> with 0.05s delay between each "keypress": xdotool selectwindow ==> (record window ID) seq 99 -1 0 | xargs -n1 sh -c 'xdotool key --window $ID 23 && sleep 0.05 && xdotool key --window $ID 116 && sleep 0.05' (23 is X keycode for <tab> and <116> for <down>) and there was 100 <tab> and 100 <down>, respectively... Dmitry ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16505: Acknowledgement (24.3.50; Emacs seems to loose key events when typing fast (seriously)) 2014-02-07 16:06 ` Dmitry Antipov @ 2014-02-07 21:03 ` Anders Lindgren 2014-02-08 20:04 ` Anders Lindgren 2014-02-08 0:14 ` Lars Ingebrigtsen 1 sibling, 1 reply; 14+ messages in thread From: Anders Lindgren @ 2014-02-07 21:03 UTC (permalink / raw) To: Dmitry Antipov; +Cc: 16505 [-- Attachment #1: Type: text/plain, Size: 1876 bytes --] Hi! I understand your scepticism about my fingers ;) However, the problem is quite apparent, I get bitten by it several times per day. Also, it occurs consistently when doing the <tab> <down> sequence in recent versions from the trunk. On older versions, however, I don't see this behaviour at all. Anyway, I tried to script this using AppleScript, asking the "System Event" to send keycodes for <tab> and <down>. Unfortunately, Emacs behaves perfectly and doesn't loose any key event when scripted. Just for the record, this is the script I used: repeat 100 times tell application "System Events" to key code 48 -- TAB tell application "System Events" to key code 125 -- DOWN end I started it from within emacs using M-! osascript xxx.osa RET One approach to find the faulty revision is to back-patch the fix in 111505 into the revisions 110812-111504 to see if one of those revisions introduced the problem. (If the problem is in the sequence 110786-110811, it will be harder to track down, as they don't build properly). I will try to find the time to do this, but I can't give any guarantees... -- Anders On Fri, Feb 7, 2014 at 5:06 PM, Dmitry Antipov <dmantipov@yandex.ru> wrote: > On 02/07/2014 06:17 PM, Anders Lindgren wrote: > > Here, a <tab> is missing, which explains the indentation problems. >> > > Hmm...IMHO we shouldn't believe in anyone's fingers in such a case :-). > > Do you have a tool to fake user input? On X, we have xdotool. I've tried > to insert 100 <tab> and 100 <down> with 0.05s delay between each > "keypress": > > xdotool selectwindow ==> (record window ID) > > seq 99 -1 0 | xargs -n1 sh -c 'xdotool key --window $ID 23 && sleep 0.05 > && xdotool key --window $ID 116 && sleep 0.05' > > (23 is X keycode for <tab> and <116> for <down>) and there was 100 <tab> > and > 100 <down>, respectively... > > Dmitry > > [-- Attachment #2: Type: text/html, Size: 2817 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16505: Acknowledgement (24.3.50; Emacs seems to loose key events when typing fast (seriously)) 2014-02-07 21:03 ` Anders Lindgren @ 2014-02-08 20:04 ` Anders Lindgren 2014-02-08 20:29 ` Eli Zaretskii 0 siblings, 1 reply; 14+ messages in thread From: Anders Lindgren @ 2014-02-08 20:04 UTC (permalink / raw) To: 16505; +Cc: larsi, Dmitry Antipov [-- Attachment #1: Type: text/plain, Size: 2931 bytes --] Hi! I have narrowed down the possible bzr revision candidates. 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. 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? -- Anders On Fri, Feb 7, 2014 at 10:03 PM, Anders Lindgren <andlind@gmail.com> wrote: > Hi! > > I understand your scepticism about my fingers ;) However, the problem is > quite apparent, I get bitten by it several times per day. Also, it occurs > consistently when doing the <tab> <down> sequence in recent versions from > the trunk. On older versions, however, I don't see this behaviour at all. > > Anyway, I tried to script this using AppleScript, asking the "System > Event" to send keycodes for <tab> and <down>. Unfortunately, Emacs behaves > perfectly and doesn't loose any key event when scripted. > > Just for the record, this is the script I used: > > repeat 100 times > tell application "System Events" to key code 48 -- TAB > tell application "System Events" to key code 125 -- DOWN > end > > I started it from within emacs using M-! osascript xxx.osa RET > > One approach to find the faulty revision is to back-patch the fix in > 111505 into the revisions 110812-111504 to see if one of those revisions > introduced the problem. (If the problem is in the sequence 110786-110811, > it will be harder to track down, as they don't build properly). I will try > to find the time to do this, but I can't give any guarantees... > > -- Anders > > > On Fri, Feb 7, 2014 at 5:06 PM, Dmitry Antipov <dmantipov@yandex.ru>wrote: > >> On 02/07/2014 06:17 PM, Anders Lindgren wrote: >> >> Here, a <tab> is missing, which explains the indentation problems. >>> >> >> Hmm...IMHO we shouldn't believe in anyone's fingers in such a case :-). >> >> Do you have a tool to fake user input? On X, we have xdotool. I've tried >> to insert 100 <tab> and 100 <down> with 0.05s delay between each >> "keypress": >> >> xdotool selectwindow ==> (record window ID) >> >> seq 99 -1 0 | xargs -n1 sh -c 'xdotool key --window $ID 23 && sleep 0.05 >> && xdotool key --window $ID 116 && sleep 0.05' >> >> (23 is X keycode for <tab> and <116> for <down>) and there was 100 <tab> >> and >> 100 <down>, respectively... >> >> Dmitry >> >> > [-- Attachment #2: Type: text/html, Size: 4368 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16505: Acknowledgement (24.3.50; Emacs seems to loose key events when typing fast (seriously)) 2014-02-08 20:04 ` Anders Lindgren @ 2014-02-08 20:29 ` Eli Zaretskii 2014-02-09 12:56 ` Anders Lindgren 0 siblings, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2014-02-08 20:29 UTC (permalink / raw) To: Anders Lindgren; +Cc: 16505, larsi, dmantipov > 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16505: Acknowledgement (24.3.50; Emacs seems to loose key events when typing fast (seriously)) 2014-02-08 20:29 ` Eli Zaretskii @ 2014-02-09 12:56 ` Anders Lindgren 2014-02-16 7:42 ` Anders Lindgren 0 siblings, 1 reply; 14+ messages in thread From: Anders Lindgren @ 2014-02-09 12:56 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 16505, larsi, Dmitry Antipov [-- Attachment #1: Type: text/plain, Size: 1790 bytes --] 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. > [-- Attachment #2: Type: text/html, Size: 2785 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16505: Acknowledgement (24.3.50; Emacs seems to loose key events when typing fast (seriously)) 2014-02-09 12:56 ` Anders Lindgren @ 2014-02-16 7:42 ` Anders Lindgren 2014-02-16 9:52 ` Jan D. 0 siblings, 1 reply; 14+ messages in thread From: Anders Lindgren @ 2014-02-16 7:42 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 16505, Lars Ingebrigtsen, Dmitry Antipov [-- Attachment #1: Type: text/plain, Size: 3325 bytes --] 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. >> > > [-- Attachment #2: Type: text/html, Size: 5458 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16505: Acknowledgement (24.3.50; Emacs seems to loose key events when typing fast (seriously)) 2014-02-16 7:42 ` Anders Lindgren @ 2014-02-16 9:52 ` Jan D. 0 siblings, 0 replies; 14+ messages in thread From: Jan D. @ 2014-02-16 9:52 UTC (permalink / raw) To: Anders Lindgren; +Cc: 16505-done, Dmitry Antipov, Lars Ingebrigtsen 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@gmail.com > <mailto: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 > <mailto:tralfaz@pacbell.net>> > committer: Chong Yidong <cyd@gnu.org <mailto: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 > <mailto:eliz@gnu.org>> wrote: > > > Date: Sat, 8 Feb 2014 21:04:13 +0100 > > From: Anders Lindgren <andlind@gmail.com > <mailto:andlind@gmail.com>> > > Cc: Dmitry Antipov <dmantipov@yandex.ru > <mailto:dmantipov@yandex.ru>>, larsi@gnus.org > <mailto:larsi@gnus.org>, Eli Zaretskii <eliz@gnu.org > <mailto: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. > > > ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16505: Acknowledgement (24.3.50; Emacs seems to loose key events when typing fast (seriously)) 2014-02-07 16:06 ` Dmitry Antipov 2014-02-07 21:03 ` Anders Lindgren @ 2014-02-08 0:14 ` Lars Ingebrigtsen 2014-02-08 8:47 ` Eli Zaretskii 1 sibling, 1 reply; 14+ messages in thread From: Lars Ingebrigtsen @ 2014-02-08 0:14 UTC (permalink / raw) To: Dmitry Antipov; +Cc: 16505, Anders Lindgren Dmitry Antipov <dmantipov@yandex.ru> writes: >> Here, a <tab> is missing, which explains the indentation problems. > > Hmm...IMHO we shouldn't believe in anyone's fingers in such a case :-). I have seen Emacs drop characters if you keep Emacs busy doing other things, like showing an animated image. Emacs didn't use to lose characters in that scenario. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16505: Acknowledgement (24.3.50; Emacs seems to loose key events when typing fast (seriously)) 2014-02-08 0:14 ` Lars Ingebrigtsen @ 2014-02-08 8:47 ` Eli Zaretskii 2014-02-08 10:22 ` Lars Ingebrigtsen 0 siblings, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2014-02-08 8:47 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 16505, dmantipov, andlind > From: Lars Ingebrigtsen <larsi@gnus.org> > Date: Fri, 07 Feb 2014 16:14:10 -0800 > Cc: 16505@debbugs.gnu.org, Anders Lindgren <andlind@gmail.com> > > I have seen Emacs drop characters if you keep Emacs busy doing other > things, like showing an animated image. Emacs didn't use to lose > characters in that scenario. I have a hard time believing this. Unless the OS itself drops the characters (and I don't think any modern OS does), you'd have to come with a plausible hypothesis for how this can happen on a particular OS with a particular mechanism of keyboard input handling by Emacs on that OS. Doesn't the OS buffer keys without discarding them until the application actually reads them? On systems that use interrupts for Emacs keyboard input, what happens with the keys you type if the interrupts are blocked for prolonged times? I hope Emacs never ignores these interrupts, but what happens if it does? Once a key was read by Emacs, there's simply no mechanism in Emacs I know of to "drop" it. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16505: Acknowledgement (24.3.50; Emacs seems to loose key events when typing fast (seriously)) 2014-02-08 8:47 ` Eli Zaretskii @ 2014-02-08 10:22 ` Lars Ingebrigtsen 2014-02-08 10:53 ` Eli Zaretskii 0 siblings, 1 reply; 14+ messages in thread From: Lars Ingebrigtsen @ 2014-02-08 10:22 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 16505, dmantipov, andlind Eli Zaretskii <eliz@gnu.org> writes: > I have a hard time believing this. Unless the OS itself drops the > characters (and I don't think any modern OS does), you'd have to come > with a plausible hypothesis for how this can happen on a particular OS > with a particular mechanism of keyboard input handling by Emacs on > that OS. I just tells em as I sees em. I've been unable to come up with a test case, though. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#16505: Acknowledgement (24.3.50; Emacs seems to loose key events when typing fast (seriously)) 2014-02-08 10:22 ` Lars Ingebrigtsen @ 2014-02-08 10:53 ` Eli Zaretskii 0 siblings, 0 replies; 14+ messages in thread From: Eli Zaretskii @ 2014-02-08 10:53 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 16505, dmantipov, andlind > From: Lars Ingebrigtsen <larsi@gnus.org> > Cc: dmantipov@yandex.ru, 16505@debbugs.gnu.org, andlind@gmail.com > Date: Sat, 08 Feb 2014 02:22:30 -0800 > > Eli Zaretskii <eliz@gnu.org> writes: > > > I have a hard time believing this. Unless the OS itself drops the > > characters (and I don't think any modern OS does), you'd have to come > > with a plausible hypothesis for how this can happen on a particular OS > > with a particular mechanism of keyboard input handling by Emacs on > > that OS. > > I just tells em as I sees em. I understand that. I'm saying we will need a good working hypothesis for how this can happen, before we will be able to do anything about this. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2014-02-16 9:52 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-01-20 15:25 bug#16505: 24.3.50; Emacs seems to loose key events when typing fast (seriously) Anders Lindgren [not found] ` <handler.16505.B.139023152917540.ack@debbugs.gnu.org> 2014-01-20 15:36 ` bug#16505: Acknowledgement (24.3.50; Emacs seems to loose key events when typing fast (seriously)) Anders Lindgren 2014-02-07 14:17 ` Anders Lindgren 2014-02-07 16:06 ` Dmitry Antipov 2014-02-07 21:03 ` Anders Lindgren 2014-02-08 20:04 ` Anders Lindgren 2014-02-08 20:29 ` Eli Zaretskii 2014-02-09 12:56 ` Anders Lindgren 2014-02-16 7:42 ` Anders Lindgren 2014-02-16 9:52 ` Jan D. 2014-02-08 0:14 ` Lars Ingebrigtsen 2014-02-08 8:47 ` Eli Zaretskii 2014-02-08 10:22 ` Lars Ingebrigtsen 2014-02-08 10:53 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.