* bug#6758: 23.2; xterm.el: please provide an option to not discard input in terminal-init-xterm @ 2010-07-29 20:15 Jim Paris 2010-08-01 23:03 ` Stefan Monnier ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Jim Paris @ 2010-07-29 20:15 UTC (permalink / raw) To: 6758; +Cc: jim This bug report will be sent to the Free Software Foundation, not to your local site managers! Please write in English if possible, because the Emacs maintainers usually do not have translators to read other languages for them. Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list, and to the gnu.emacs.bug news group. Please describe exactly what actions triggered the bug and the precise symptoms of the bug. If you can, give a recipe starting from `emacs -Q': Since upgrading to emacs-23, the terminal-init-xterm function in term/xterm.el performs a "discard-input" followed by a couple of xterm queries. You can see the effect of this in the "recent input" line below -- all I did was start emacs and do M-x report-bug, the preceding input was generated by the xterm in response to terminal-init-xterm's queries. This causes several problems when I start emacs in a terminal: - Everything that I type while emacs is still loading gets discarded. This problem is more common than you might initially think, because I very frequently load emacs and immediately hit C-s to search for something. Now, the C-s gets lost and my search terms go into the buffer instead. To reproduce this, just start emacs (preferably on a slow machine, or one with delays in ~/.emacs, for example) and start typing before emacs has finished loading. Everything typed is lost. - There are race conditions here. If I'm typing when this query-response happens, my typing is discarded by terminal-init-xterm, and the actual xterm response gets inserted directly into my buffer as if I had typed it. Since I type quickly, I see this quite frequently: I load emacs, start typing, and the buffer ends up with "0;251;0c" rather than what I had typed. This one is harder to reproduce, but it is not difficult for me if I just run "emacs -nw" from the commandline and quickly hit "asdfasdf" while it's loading. I understand that the modify-other-keys feature is useful, but this makes emacs-23 difficult to use. Can an option be provided to disable these probes? Maybe we can just skip the discard-input and query/response if the user provides, say, predetermined "xterm-version" and "xterm-background-color" variables in their ~/.emacs? That seems to be the quickest and easiest approach, although it requires user intervention to work around the issue. I can also imagine a more complete fix that would involve not flushing the input buffer, and interpreting the Xterm responses in a more asynchronous fashion: - Don't discard input - Send the \e[>0c probe - Allow input into the buffer as usual, but for the next few seconds, interpret \e[>0;251;0c responses and perform (xterm-turn-on-modify-other-keys) etc. as necessary. -jim If Emacs crashed, and you have the Emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. For information about debugging Emacs, please read the file /usr/share/emacs/23.2/etc/DEBUG. In GNU Emacs 23.2.1 (x86_64-pc-linux-gnu, GTK+ Version 2.20.1) of 2010-05-16 on barber, modified by Debian configured using `configure '--build' 'x86_64-linux-gnu' '--build' 'x86_64-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.2/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.2/leim' '--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g' 'CPPFLAGS='' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: en_US.UTF-8 value of $LC_MESSAGES: en_US value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: POSIX value of $XMODIFIERS: nil locale-coding-system: utf-8-unix default enable-multibyte-characters: t Major mode: Text Minor modes in effect: tooltip-mode: t mouse-wheel-mode: t tool-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t auto-encryption-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: ESC [ > 0 ; 2 5 1 ; 0 c ESC ] 1 1 ; r g b : 0 0 0 0 / 0 0 0 0 / 0 0 0 0 ESC \ ESC x r e p o r t TAB RE T Recent messages: Loading /etc/emacs/site-start.d/50namazu2.el (source)...done Loading /etc/emacs/site-start.d/50php-elisp.el (source)...done Loading /etc/emacs/site-start.d/50psvn.el (source)...done Loading /etc/emacs/site-start.d/51debian-el.el (source)...done Loading /etc/emacs/site-start.d/70jim.el (source)... Toggling menu-bar-mode off; better pass an explicit argument. Ready. Loading /etc/emacs/site-start.d/70jim.el (source)...done Loading quail/latin-ltx...done Ready. Load-path shadows: /usr/share/emacs/23.2/site-lisp/debian-startup hides /usr/share/emacs/site-lisp/debian-startup /usr/share/emacs23/site-lisp/easypg/epg hides /usr/share/emacs/23.2/lisp/epg /usr/share/emacs23/site-lisp/easypg/epa-mail hides /usr/share/emacs/23.2/lisp/epa-mail /usr/share/emacs23/site-lisp/easypg/epa-dired hides /usr/share/emacs/23.2/lisp/epa-dired /usr/share/emacs23/site-lisp/flim/sha1 hides /usr/share/emacs/23.2/lisp/sha1 /usr/share/emacs23/site-lisp/easypg/epa-file hides /usr/share/emacs/23.2/lisp/epa-file /usr/share/emacs23/site-lisp/emacs-goodies-el/ido hides /usr/share/emacs/23.2/lisp/ido /usr/share/emacs23/site-lisp/flim/md4 hides /usr/share/emacs/23.2/lisp/md4 /usr/share/emacs23/site-lisp/emacs-goodies-el/ibuffer hides /usr/share/emacs/23.2/lisp/ibuffer /usr/share/emacs23/site-lisp/emacs-goodies-el/wdired hides /usr/share/emacs/23.2/lisp/wdired /usr/share/emacs23/site-lisp/flim/hex-util hides /usr/share/emacs/23.2/lisp/hex-util /usr/share/emacs23/site-lisp/easypg/epg-config hides /usr/share/emacs/23.2/lisp/epg-config /usr/share/emacs23/site-lisp/easypg/epa hides /usr/share/emacs/23.2/lisp/epa /usr/share/emacs23/site-lisp/dictionaries-common/ispell hides /usr/share/emacs/23.2/lisp/textmodes/ispell /usr/share/emacs23/site-lisp/emacs-goodies-el/table hides /usr/share/emacs/23.2/lisp/textmodes/table /usr/share/emacs23/site-lisp/dictionaries-common/flyspell hides /usr/share/emacs/23.2/lisp/textmodes/flyspell /usr/share/emacs23/site-lisp/emacs-goodies-el/cfengine hides /usr/share/emacs/23.2/lisp/progmodes/cfengine /usr/share/emacs23/site-lisp/flim/ntlm hides /usr/share/emacs/23.2/lisp/net/ntlm /usr/share/emacs23/site-lisp/flim/hmac-def hides /usr/share/emacs/23.2/lisp/net/hmac-def /usr/share/emacs23/site-lisp/flim/sasl hides /usr/share/emacs/23.2/lisp/net/sasl /usr/share/emacs23/site-lisp/emacs-goodies-el/newsticker hides /usr/share/emacs/23.2/lisp/net/newsticker /usr/share/emacs23/site-lisp/flim/sasl-digest hides /usr/share/emacs/23.2/lisp/net/sasl-digest /usr/share/emacs23/site-lisp/flim/hmac-md5 hides /usr/share/emacs/23.2/lisp/net/hmac-md5 /usr/share/emacs23/site-lisp/flim/sasl-ntlm hides /usr/share/emacs/23.2/lisp/net/sasl-ntlm /usr/share/emacs23/site-lisp/flim/sasl-cram hides /usr/share/emacs/23.2/lisp/net/sasl-cram /usr/share/emacs23/site-lisp/latex-cjk-thai/thai-word hides /usr/share/emacs/23.2/lisp/language/thai-word Features: (shadow sort mail-extr message sendmail regexp-opt ecomplete rfc822 mml mml-sec password-cache mm-decode mm-bodies mm-encode mailcap mail-parse rfc2231 rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util netrc time-date mm-util mail-prsvr gmm-utils wid-edit mailheader canlock sha1 sha1-el hex-util hashcash mail-utils warnings emacsbug quail help-mode easymenu view debian-el debian-el-loaddefs path-util byte-opt bytecomp byte-compile advice help-fns advice-preload poe pym static apel-ver product emacs-goodies-el emacs-goodies-custom emacs-goodies-loaddefs epa-setup epa-file epa derived epg epg-config epg-package-info dpkg-dev-el dpkg-dev-el-loaddefs tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd font-setting tool-bar dnd fontset image fringe lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar mldrag 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 loaddefs button minibuffer faces cus-face files text-properties overlay md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process dbusbind system-font-setting font-render-setting gtk x-toolkit x multi-tty emacs) ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6758: 23.2; xterm.el: please provide an option to not discard input in terminal-init-xterm 2010-07-29 20:15 bug#6758: 23.2; xterm.el: please provide an option to not discard input in terminal-init-xterm Jim Paris @ 2010-08-01 23:03 ` Stefan Monnier 2010-08-02 20:38 ` Johan Bockgård 2010-08-02 20:59 ` Jim Paris 2012-06-17 5:28 ` Chong Yidong 2012-06-19 4:03 ` bug#6758: So what do I need to do to keep emacs from eating my typeahead? Karl O. Pinc 2 siblings, 2 replies; 15+ messages in thread From: Stefan Monnier @ 2010-08-01 23:03 UTC (permalink / raw) To: Jim Paris; +Cc: 6758 > I can also imagine a more complete fix that would involve not flushing > the input buffer, and interpreting the Xterm responses in a more > asynchronous fashion: > - Don't discard input > - Send the \e[>0c probe > - Allow input into the buffer as usual, but for the next few seconds, > interpret \e[>0;251;0c responses and perform > (xterm-turn-on-modify-other-keys) etc. as necessary. Time-dependent processing is considered brittle (especially when working remotely via something like SSH), so we prefer to avoid it. Especially since coding it right could prove pretty darn tricky. OTOH, I thought we had agreed that we need to add a configuration variable xterm-turn-on-modify-other-keys which could be set to t or nil to force the modifyOtherKeys feature of Xterm ON or OFF without first checking whether the current xterm indeed supports it or not. Its default value would be `auto', which would first check for support and then turn it ON if applicable. Since the "discard input" is needed for the check, this would solve your problem. Now, I don't see such a variable, so either I misremeber, or the patch was never written, or never committed, ... Stefan ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6758: 23.2; xterm.el: please provide an option to not discard input in terminal-init-xterm 2010-08-01 23:03 ` Stefan Monnier @ 2010-08-02 20:38 ` Johan Bockgård 2010-08-02 20:59 ` Jim Paris 1 sibling, 0 replies; 15+ messages in thread From: Johan Bockgård @ 2010-08-02 20:38 UTC (permalink / raw) To: Stefan Monnier; +Cc: 6758, Jim Paris Stefan Monnier <monnier@iro.umontreal.ca> writes: > OTOH, I thought we had agreed that we need to add a configuration > variable xterm-turn-on-modify-other-keys which could be set to t or nil > to force the modifyOtherKeys feature of Xterm ON or OFF without first > checking whether the current xterm indeed supports it or not. > Its default value would be `auto', which would first check for support > and then turn it ON if applicable. > Since the "discard input" is needed for the check, this would solve > your problem. > > Now, I don't see such a variable, so either I misremeber, or the patch > was never written, or never committed, ... http://lists.gnu.org/archive/html/emacs-devel/2009-08/msg01276.html ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6758: 23.2; xterm.el: please provide an option to not discard input in terminal-init-xterm 2010-08-01 23:03 ` Stefan Monnier 2010-08-02 20:38 ` Johan Bockgård @ 2010-08-02 20:59 ` Jim Paris 2010-08-02 21:27 ` Andreas Schwab 2010-08-02 22:21 ` Stefan Monnier 1 sibling, 2 replies; 15+ messages in thread From: Jim Paris @ 2010-08-02 20:59 UTC (permalink / raw) To: Stefan Monnier, Johan Bockgård; +Cc: 6758 Stefan Monnier wrote: > > I can also imagine a more complete fix that would involve not flushing > > the input buffer, and interpreting the Xterm responses in a more > > asynchronous fashion: > > - Don't discard input > > - Send the \e[>0c probe > > - Allow input into the buffer as usual, but for the next few seconds, > > interpret \e[>0;251;0c responses and perform > > (xterm-turn-on-modify-other-keys) etc. as necessary. > > Time-dependent processing is considered brittle (especially when > working remotely via something like SSH), so we prefer to avoid it. > Especially since coding it right could prove pretty darn tricky. Forget the time-dependent part of what I said, let's just send the query and handle the response whenever it happens to come in. See the below patch. This fixes everything -- it still detects both modifyOtherKeys and the background color, but doesn't require flushing input or rely on any timeouts at all, unlike the existing code. And there's nothing tricky. What do you think? > OTOH, I thought we had agreed that we need to add a configuration > variable xterm-turn-on-modify-other-keys which could be set to t or nil > to force the modifyOtherKeys feature of Xterm ON or OFF without first > checking whether the current xterm indeed supports it or not. > Its default value would be `auto', which would first check for support > and then turn it ON if applicable. This may still be useful for people who don't want any queries sent to their terminal. -jim --- xterm.el-orig 2010-04-03 18:26:04.000000000 -0400 +++ xterm.el 2010-08-02 16:51:45.000000000 -0400 @@ -440,6 +440,65 @@ ;; List of terminals for which modify-other-keys has been turned on. (defvar xterm-modify-other-keys-terminal-list nil) +(defun xterm-osc-translate (event) + "Read and handle a Operating System Controls response" + (let* ((str "") + (chr nil) + (recompute-faces nil)) + + ;; The reply should be of the form: \e ] 11 ; rgb: NUMBER1 / NUMBER2 / NUMBER3 \e \\ + (while (not (equal (setq chr (read-char)) ?\\)) + (setq str (concat str (string chr)))) + + (when (string-match "rgb:\\([a-f0-9]+\\)/\\([a-f0-9]+\\)/\\([a-f0-9]+\\)" str) + (setq recompute-faces + (xterm-maybe-set-dark-background-mode + (string-to-number (match-string 1 str) 16) + (string-to-number (match-string 2 str) 16) + (string-to-number (match-string 3 str) 16)))) + + (when recompute-faces + (tty-set-up-initial-frame-faces)) + + "")) + +(defun xterm-secondary-da-translate (event) + "Read and handle a Secondary Device Attributes response" + (let* ((str "") + (chr nil) + version) + + ;; The reply should be of the form: \e [ > NUMBER1 ; NUMBER2 ; NUMBER3 c + (while (not (equal (setq chr (read-char)) ?c)) + (setq str (concat str (string chr)))) + + (when (string-match "0;\\([0-9]+\\);0" str) + (setq version (string-to-number + (substring str (match-beginning 1) (match-end 1)))) + ;; NUMBER2 is the xterm version number, look for something + ;; greater than 216, the version when modifyOtherKeys was + ;; introduced. + (when (>= version 216) + ;; Make sure that the modifyOtherKeys state is restored when + ;; suspending, resuming and exiting. + (add-hook 'suspend-hook 'xterm-turn-off-modify-other-keys) + (add-hook 'suspend-resume-hook 'xterm-turn-on-modify-other-keys) + (add-hook 'kill-emacs-hook 'xterm-remove-modify-other-keys) + (add-hook 'delete-terminal-functions 'xterm-remove-modify-other-keys) + ;; Add the selected frame to the list of frames that + ;; need to deal with modify-other-keys. + (push (frame-terminal (selected-frame)) + xterm-modify-other-keys-terminal-list) + (xterm-turn-on-modify-other-keys)) + + ;; xterm version 235 supports reporting the background + ;; color, maybe earlier versions do too... + (when (>= version 235) + (define-key input-decode-map "\e]11;" 'xterm-osc-translate) + (send-string-to-terminal "\e]11;?\e\\"))) + + "")) + (defun terminal-init-xterm () "Terminal initialization function for xterm." ;; rxvt terminals sometimes set the TERM variable to "xterm", but @@ -469,71 +528,12 @@ ;; C-. C-, etc. ;; To do that we need to find out if the current terminal supports ;; modifyOtherKeys. At this time only xterm does. - (let ((coding-system-for-read 'binary) - (chr nil) - (str nil) - (recompute-faces nil) - version) - ;; Pending input can be mistakenly returned by the calls to - ;; read-event below. Discard it. - (discard-input) - ;; Try to find out the type of terminal by sending a "Secondary - ;; Device Attributes (DA)" query. - (send-string-to-terminal "\e[>0c") - - ;; The reply should be of the form: \e [ > NUMBER1 ; NUMBER2 ; NUMBER3 c - ;; If the timeout is completely removed for read-event, this - ;; might hang for terminals that pretend to be xterm, but don't - ;; respond to this escape sequence. RMS' opinion was to remove - ;; it completely. That might be right, but let's first try to - ;; see if by using a longer timeout we get rid of most issues. - (when (equal (read-event nil nil 2) ?\e) - (when (equal (read-event nil nil 2) ?\[) - (while (not (equal (setq chr (read-event nil nil 2)) ?c)) - (setq str (concat str (string chr)))) - (when (string-match ">0;\\([0-9]+\\);0" str) - (setq version (string-to-number - (substring str (match-beginning 1) (match-end 1)))) - ;; xterm version 242 supports reporting the background - ;; color, maybe earlier versions do too... - (when (>= version 242) - (send-string-to-terminal "\e]11;?\e\\") - (when (equal (read-event nil nil 2) ?\e) - (when (equal (read-event nil nil 2) ?\]) - (setq str "") - (while (not (equal (setq chr (read-event nil nil 2)) ?\\)) - (setq str (concat str (string chr)))) - (when (string-match "11;rgb:\\([a-f0-9]+\\)/\\([a-f0-9]+\\)/\\([a-f0-9]+\\)" str) - (setq recompute-faces - (xterm-maybe-set-dark-background-mode - (string-to-number (match-string 1 str) 16) - (string-to-number (match-string 2 str) 16) - (string-to-number (match-string 3 str) 16))))))) - ;; NUMBER2 is the xterm version number, look for something - ;; greater than 216, the version when modifyOtherKeys was - ;; introduced. - (when (>= version 216) - ;; Make sure that the modifyOtherKeys state is restored when - ;; suspending, resuming and exiting. - (add-hook 'suspend-hook 'xterm-turn-off-modify-other-keys) - (add-hook 'suspend-resume-hook 'xterm-turn-on-modify-other-keys) - (add-hook 'kill-emacs-hook 'xterm-remove-modify-other-keys) - (add-hook 'delete-terminal-functions 'xterm-remove-modify-other-keys) - ;; Add the selected frame to the list of frames that - ;; need to deal with modify-other-keys. - (push (frame-terminal (selected-frame)) - xterm-modify-other-keys-terminal-list) - (xterm-turn-on-modify-other-keys)) - - ;; Recompute faces here in case the background mode was - ;; set to dark. We used to call - ;; `tty-set-up-initial-frame-faces' only once, but that - ;; caused the light background faces to be computed - ;; incorrectly. See: - ;; http://permalink.gmane.org/gmane.emacs.devel/119627 - (when recompute-faces - (tty-set-up-initial-frame-faces)))))) + ;; Try to find out the type of terminal by sending a "Secondary + ;; Device Attributes (DA)" query. + (define-key input-decode-map "\e[>" 'xterm-secondary-da-translate) + (send-string-to-terminal "\e[>0c") + (run-hooks 'terminal-init-xterm-hook)) ;; Set up colors, for those versions of xterm that support it. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6758: 23.2; xterm.el: please provide an option to not discard input in terminal-init-xterm 2010-08-02 20:59 ` Jim Paris @ 2010-08-02 21:27 ` Andreas Schwab 2010-08-02 21:36 ` Jim Paris 2010-08-02 22:21 ` Stefan Monnier 1 sibling, 1 reply; 15+ messages in thread From: Andreas Schwab @ 2010-08-02 21:27 UTC (permalink / raw) To: Jim Paris; +Cc: 6758, Johan, ård Jim Paris <jim@jtan.com> writes: > + ;; The reply should be of the form: \e ] 11 ; rgb: NUMBER1 / NUMBER2 / NUMBER3 \e \\ > + (while (not (equal (setq chr (read-char)) ?\\)) > + (setq str (concat str (string chr)))) At least this loop needs to have a timeout, in case the terminator character gets lost for whatever reason. > + ;; The reply should be of the form: \e [ > NUMBER1 ; NUMBER2 ; NUMBER3 c > + (while (not (equal (setq chr (read-char)) ?c)) > + (setq str (concat str (string chr)))) Likewise. (It isn't all that hard to type ESC [ > by accident). Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6758: 23.2; xterm.el: please provide an option to not discard input in terminal-init-xterm 2010-08-02 21:27 ` Andreas Schwab @ 2010-08-02 21:36 ` Jim Paris 0 siblings, 0 replies; 15+ messages in thread From: Jim Paris @ 2010-08-02 21:36 UTC (permalink / raw) To: Andreas Schwab; +Cc: 6758, Johan Bockgård Andreas Schwab wrote: > Jim Paris <jim@jtan.com> writes: > > > + ;; The reply should be of the form: \e ] 11 ; rgb: NUMBER1 / NUMBER2 / NUMBER3 \e \\ > > + (while (not (equal (setq chr (read-char)) ?\\)) > > + (setq str (concat str (string chr)))) > > At least this loop needs to have a timeout, in case the terminator > character gets lost for whatever reason. > > > + ;; The reply should be of the form: \e [ > NUMBER1 ; NUMBER2 ; NUMBER3 c > > + (while (not (equal (setq chr (read-char)) ?c)) > > + (setq str (concat str (string chr)))) > > Likewise. (It isn't all that hard to type ESC [ > by accident). Ok, (read-char) can be replaced with (read-event nil nil 2). There may also need to be a (let (coding-system-for-read 'binary)) in there somewhere -- I'm really not familiar with emacs programming, this is mostly just based on other code I've found (like xt-mouse.el) -jim ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6758: 23.2; xterm.el: please provide an option to not discard input in terminal-init-xterm 2010-08-02 20:59 ` Jim Paris 2010-08-02 21:27 ` Andreas Schwab @ 2010-08-02 22:21 ` Stefan Monnier 2010-08-03 20:14 ` Jim Paris 1 sibling, 1 reply; 15+ messages in thread From: Stefan Monnier @ 2010-08-02 22:21 UTC (permalink / raw) To: Jim Paris; +Cc: 6758, Johan Bockgård > Forget the time-dependent part of what I said, let's just send the > query and handle the response whenever it happens to come in. See > the below patch. This fixes everything -- it still detects both > modifyOtherKeys and the background color, but doesn't require flushing > input or rely on any timeouts at all, unlike the existing code. > And there's nothing tricky. What do you think? Looks pretty good from here, thank you. We may want to get rid of the "\e[>" (and "\e]11;") decode rules after they've been used, just in case (or better yet: make them more robust). Any objection? Stefan ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6758: 23.2; xterm.el: please provide an option to not discard input in terminal-init-xterm 2010-08-02 22:21 ` Stefan Monnier @ 2010-08-03 20:14 ` Jim Paris 2010-08-24 0:48 ` Jim Paris 0 siblings, 1 reply; 15+ messages in thread From: Jim Paris @ 2010-08-03 20:14 UTC (permalink / raw) To: Stefan Monnier; +Cc: 6758, Johan Bockgård Stefan Monnier wrote: > > Forget the time-dependent part of what I said, let's just send the > > query and handle the response whenever it happens to come in. See > > the below patch. This fixes everything -- it still detects both > > modifyOtherKeys and the background color, but doesn't require flushing > > input or rely on any timeouts at all, unlike the existing code. > > And there's nothing tricky. What do you think? > > Looks pretty good from here, thank you. > We may want to get rid of the "\e[>" (and "\e]11;") decode rules after > they've been used, just in case (or better yet: make them more > robust). > > Any objection? I found a problem: the Mac OS X terminal sets TERM=xterm-color, but it responds to the "Secondary DA" query as if it were a "Primary DA" query. Instead of a response like xterm's "\e[>0;253;0c", it sends "\e[?1;2c". The below patch accounts for this. It also adds the 2-second timeout when reading responses, and unsets the decode rules once they're unused. -jim --- xterm.el-orig 2010-04-03 18:26:04.000000000 -0400 +++ xterm.el 2010-08-03 16:05:49.000000000 -0400 @@ -440,6 +440,86 @@ ;; List of terminals for which modify-other-keys has been turned on. (defvar xterm-modify-other-keys-terminal-list nil) +(defun xterm-osc-translate (event) + "Read and handle a Operating System Controls response" + (let* ((str "") + (chr nil) + (recompute-faces nil)) + + ;; The reply should be of the form: \e ] 11 ; rgb: NUMBER1 / NUMBER2 / NUMBER3 \e \\ + (while (not (equal (setq chr (read-event nil nil 2)) ?\\)) + (setq str (concat str (string chr)))) + + (when (string-match "rgb:\\([a-f0-9]+\\)/\\([a-f0-9]+\\)/\\([a-f0-9]+\\)" str) + (setq recompute-faces + (xterm-maybe-set-dark-background-mode + (string-to-number (match-string 1 str) 16) + (string-to-number (match-string 2 str) 16) + (string-to-number (match-string 3 str) 16)))) + + (when recompute-faces + (tty-set-up-initial-frame-faces)) + + ;; We no longer expect the OSC response + (define-key input-decode-map "\e]11;" nil) + "")) + +(defun xterm-primary-da-translate (event) + "Read and handle a Primary Device Attributes response" + (let* ((str "") + (chr nil)) + + ;; The reply should be of the form: \e [ ? Pd c + (while (not (equal (setq chr (read-event nil nil 2)) ?c)) + (setq str (concat str (string chr)))) + + ;; No need to do anything with this response. + + ;; Undefine both DA responses, as we don't expect either anymore + (define-key input-decode-map "\e[?" nil) + (define-key input-decode-map "\e[>" nil) + "")) + +(defun xterm-secondary-da-translate (event) + "Read and handle a Secondary Device Attributes response" + (let* ((str "") + (chr nil) + version) + + ;; The reply should be of the form: \e [ > NUMBER1 ; NUMBER2 ; NUMBER3 c + (while (not (equal (setq chr (read-event nil nil 2)) ?c)) + (setq str (concat str (string chr)))) + + (when (string-match "0;\\([0-9]+\\);0" str) + (setq version (string-to-number + (substring str (match-beginning 1) (match-end 1)))) + ;; NUMBER2 is the xterm version number, look for something + ;; greater than 216, the version when modifyOtherKeys was + ;; introduced. + (when (>= version 216) + ;; Make sure that the modifyOtherKeys state is restored when + ;; suspending, resuming and exiting. + (add-hook 'suspend-hook 'xterm-turn-off-modify-other-keys) + (add-hook 'suspend-resume-hook 'xterm-turn-on-modify-other-keys) + (add-hook 'kill-emacs-hook 'xterm-remove-modify-other-keys) + (add-hook 'delete-terminal-functions 'xterm-remove-modify-other-keys) + ;; Add the selected frame to the list of frames that + ;; need to deal with modify-other-keys. + (push (frame-terminal (selected-frame)) + xterm-modify-other-keys-terminal-list) + (xterm-turn-on-modify-other-keys)) + + ;; xterm version 235 supports reporting the background + ;; color, maybe earlier versions do too... + (when (>= version 235) + (define-key input-decode-map "\e]11;" 'xterm-osc-translate) + (send-string-to-terminal "\e]11;?\e\\"))) + + ;; Undefine both DA responses, as we don't expect either anymore + (define-key input-decode-map "\e[?" nil) + (define-key input-decode-map "\e[>" nil) + "")) + (defun terminal-init-xterm () "Terminal initialization function for xterm." ;; rxvt terminals sometimes set the TERM variable to "xterm", but @@ -469,71 +549,15 @@ ;; C-. C-, etc. ;; To do that we need to find out if the current terminal supports ;; modifyOtherKeys. At this time only xterm does. - (let ((coding-system-for-read 'binary) - (chr nil) - (str nil) - (recompute-faces nil) - version) - ;; Pending input can be mistakenly returned by the calls to - ;; read-event below. Discard it. - (discard-input) - ;; Try to find out the type of terminal by sending a "Secondary - ;; Device Attributes (DA)" query. - (send-string-to-terminal "\e[>0c") - - ;; The reply should be of the form: \e [ > NUMBER1 ; NUMBER2 ; NUMBER3 c - ;; If the timeout is completely removed for read-event, this - ;; might hang for terminals that pretend to be xterm, but don't - ;; respond to this escape sequence. RMS' opinion was to remove - ;; it completely. That might be right, but let's first try to - ;; see if by using a longer timeout we get rid of most issues. - (when (equal (read-event nil nil 2) ?\e) - (when (equal (read-event nil nil 2) ?\[) - (while (not (equal (setq chr (read-event nil nil 2)) ?c)) - (setq str (concat str (string chr)))) - (when (string-match ">0;\\([0-9]+\\);0" str) - (setq version (string-to-number - (substring str (match-beginning 1) (match-end 1)))) - ;; xterm version 242 supports reporting the background - ;; color, maybe earlier versions do too... - (when (>= version 242) - (send-string-to-terminal "\e]11;?\e\\") - (when (equal (read-event nil nil 2) ?\e) - (when (equal (read-event nil nil 2) ?\]) - (setq str "") - (while (not (equal (setq chr (read-event nil nil 2)) ?\\)) - (setq str (concat str (string chr)))) - (when (string-match "11;rgb:\\([a-f0-9]+\\)/\\([a-f0-9]+\\)/\\([a-f0-9]+\\)" str) - (setq recompute-faces - (xterm-maybe-set-dark-background-mode - (string-to-number (match-string 1 str) 16) - (string-to-number (match-string 2 str) 16) - (string-to-number (match-string 3 str) 16))))))) - ;; NUMBER2 is the xterm version number, look for something - ;; greater than 216, the version when modifyOtherKeys was - ;; introduced. - (when (>= version 216) - ;; Make sure that the modifyOtherKeys state is restored when - ;; suspending, resuming and exiting. - (add-hook 'suspend-hook 'xterm-turn-off-modify-other-keys) - (add-hook 'suspend-resume-hook 'xterm-turn-on-modify-other-keys) - (add-hook 'kill-emacs-hook 'xterm-remove-modify-other-keys) - (add-hook 'delete-terminal-functions 'xterm-remove-modify-other-keys) - ;; Add the selected frame to the list of frames that - ;; need to deal with modify-other-keys. - (push (frame-terminal (selected-frame)) - xterm-modify-other-keys-terminal-list) - (xterm-turn-on-modify-other-keys)) - - ;; Recompute faces here in case the background mode was - ;; set to dark. We used to call - ;; `tty-set-up-initial-frame-faces' only once, but that - ;; caused the light background faces to be computed - ;; incorrectly. See: - ;; http://permalink.gmane.org/gmane.emacs.devel/119627 - (when recompute-faces - (tty-set-up-initial-frame-faces)))))) + ;; Try to find out the type of terminal by sending a "Secondary + ;; Device Attributes (DA)" query. Some terminals (like OS X's + ;; Terminal.app) respond to this query as if it were a "Primary + ;; Device Attributes" query instead, so we should handle that too. + (define-key input-decode-map "\e[?" 'xterm-primary-da-translate) + (define-key input-decode-map "\e[>" 'xterm-secondary-da-translate) + (send-string-to-terminal "\e[>0c") + (run-hooks 'terminal-init-xterm-hook)) ;; Set up colors, for those versions of xterm that support it. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6758: 23.2; xterm.el: please provide an option to not discard input in terminal-init-xterm 2010-08-03 20:14 ` Jim Paris @ 2010-08-24 0:48 ` Jim Paris 2010-09-11 14:08 ` Stefan Monnier ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Jim Paris @ 2010-08-24 0:48 UTC (permalink / raw) To: Stefan Monnier; +Cc: 6758, Johan Bockgård Any thoughts on this patch? I've found further problems with doing aynchronous terminal queries: minibuffer prompts get aborted by the xterm response. For example, when opening up a large file: 1) Emacs loads and sends "\e[>0c" 2) Emacs prints the "File x is large (123MB), really open? (y or n)" prompt 3) Xterm sends the "\e[>0;253;0c" response, aborting the prompt Is there a way to make the (define-key input-decode-map "\e[?" nil) stuff take effect in the minibuffer too so the response can be properly handled? Or handle the xterm responses at a higher level so it doesn't matter where they get sent? Sigh, this whole terminal response stuff is a real mess and new failure modes keep popping up every month... I don't see how this can be enabled by default for anyone in its current form. -jim ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6758: 23.2; xterm.el: please provide an option to not discard input in terminal-init-xterm 2010-08-24 0:48 ` Jim Paris @ 2010-09-11 14:08 ` Stefan Monnier 2010-09-11 14:59 ` Stefan Monnier 2013-03-11 14:12 ` Stefan Monnier 2 siblings, 0 replies; 15+ messages in thread From: Stefan Monnier @ 2010-09-11 14:08 UTC (permalink / raw) To: Jim Paris; +Cc: 6758, Johan Bockgård > Any thoughts on this patch? > I've found further problems with doing aynchronous terminal queries: > minibuffer prompts get aborted by the xterm response. For example, > when opening up a large file: > 1) Emacs loads and sends "\e[>0c" > 2) Emacs prints the "File x is large (123MB), really open? (y or n)" prompt > 3) Xterm sends the "\e[>0;253;0c" response, aborting the prompt Indeed. But this one is "easy": y-or-n-p should use read-key rather than read-event, so that input-decode-map will be obeyed. Of course, that probably requires moving y-or-n-p from C to Elisp. Stefan ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6758: 23.2; xterm.el: please provide an option to not discard input in terminal-init-xterm 2010-08-24 0:48 ` Jim Paris 2010-09-11 14:08 ` Stefan Monnier @ 2010-09-11 14:59 ` Stefan Monnier 2013-03-11 14:12 ` Stefan Monnier 2 siblings, 0 replies; 15+ messages in thread From: Stefan Monnier @ 2010-09-11 14:59 UTC (permalink / raw) To: Jim Paris; +Cc: 6758, Johan Bockgård > Any thoughts on this patch? > I've found further problems with doing aynchronous terminal queries: > minibuffer prompts get aborted by the xterm response. For example, > when opening up a large file: > 1) Emacs loads and sends "\e[>0c" > 2) Emacs prints the "File x is large (123MB), really open? (y or n)" prompt > 3) Xterm sends the "\e[>0;253;0c" response, aborting the prompt You can try the patch below (may require manual application, it's made against a non-vanilla tree) to see if it fixes your problem, Stefan === modified file 'lisp/subr.el' --- lisp/subr.el 2010-09-11 09:14:23 +0000 +++ lisp/subr.el 2010-09-11 14:57:41 +0000 @@ -3680,6 +3680,52 @@ buffer) +(defun y-or-n-p (prompt) + "Ask user a \"y or n\" question. Return t if answer is \"y\". +The argument PROMPT is the string to display to ask the question. +It should end in a space; `y-or-n-p' adds `(y or n) ' to it. +No confirmation of the answer is requested; a single character is enough. +Also accepts Space to mean yes, or Delete to mean no. \(Actually, it uses +the bindings in `query-replace-map'; see the documentation of that variable +for more information. In this case, the useful bindings are `act', `skip', +`recenter', and `quit'.\) + +Under a windowing system a dialog box will be used if `last-nonmenu-event' +is nil and `use-dialog-box' is non-nil." + (let ((answer 'none) + (xprompt (setq prompt (propertize (concat prompt "(y or n) ") + 'face 'minibuffer-prompt)))) + (if (and (display-popup-menus-p) + (listp last-nonmenu-event) + use-dialog-box) + (progn + (setq answer + (x-popup-dialog t `(,prompt ("yes" . t) ("No" . nil))))) + (while + (progn + (when minibuffer-auto-raise + (raise-frame (window-frame (minibuffer-window)))) + (let* ((key + (let ((cursor-in-echo-area t)) + (read-key xprompt)))) + (setq answer (lookup-key query-replace-map (vector key) t)) + (case answer + ((skip act) nil) + (recenter (recenter) t) + ((exit-prefix quit) (signal 'quit nil) t) + (t t)))) + (ding) + (discard-input) + (setq xprompt + (if (eq answer 'recenter) prompt + (propertize (concat "Please answer y or n. " prompt) + 'face 'minibuffer-prompt)))) + + (let ((ret (eq answer 'act))) + (unless noninteractive + (message "%s %s" prompt (if ret "y" "n"))) + ret)))) + ;; (defun get-doc-string (pos &optional unibyte definition) ;; (let ((file (or (car-safe pos) internal-doc-file-name)) ;; (position (or (cdr-safe pos) pos)) === modified file 'src/fileio.c' --- src/fileio.c 2010-08-10 10:46:59 +0000 +++ src/fileio.c 2010-09-11 14:22:33 +0000 @@ -1842,7 +1842,7 @@ tem = format2 ("File %s already exists; %s anyway? ", absname, build_string (querystring)); if (quick) - tem = Fy_or_n_p (tem); + tem = call1 (intern ("y-or-n-p"), tem); else tem = do_yes_or_no_p (tem); UNGCPRO; === modified file 'src/fns.c' --- src/fns.c 2010-08-14 22:35:37 +0000 +++ src/fns.c 2010-09-11 14:10:27 +0000 @@ -2437,146 +2437,6 @@ return sequence; } \f -/* Anything that calls this function must protect from GC! */ - -DEFUN ("y-or-n-p", Fy_or_n_p, Sy_or_n_p, 1, 1, 0, - doc: /* Ask user a "y or n" question. Return t if answer is "y". -Takes one argument, which is the string to display to ask the question. -It should end in a space; `y-or-n-p' adds `(y or n) ' to it. -No confirmation of the answer is requested; a single character is enough. -Also accepts Space to mean yes, or Delete to mean no. \(Actually, it uses -the bindings in `query-replace-map'; see the documentation of that variable -for more information. In this case, the useful bindings are `act', `skip', -`recenter', and `quit'.\) - -Under a windowing system a dialog box will be used if `last-nonmenu-event' -is nil and `use-dialog-box' is non-nil. */) - (Lisp_Object prompt) -{ - register Lisp_Object obj, key, def, map; - register int answer; - Lisp_Object xprompt; - Lisp_Object args[2]; - struct gcpro gcpro1, gcpro2; - int count = SPECPDL_INDEX (); - - specbind (Qcursor_in_echo_area, Qt); - - map = Fsymbol_value (intern ("query-replace-map")); - - CHECK_STRING (prompt); - xprompt = prompt; - GCPRO2 (prompt, xprompt); - -#ifdef HAVE_WINDOW_SYSTEM - if (display_hourglass_p) - cancel_hourglass (); -#endif - - while (1) - { - -#ifdef HAVE_MENUS - if (FRAME_WINDOW_P (SELECTED_FRAME ()) - && (NILP (last_nonmenu_event) || CONSP (last_nonmenu_event)) - && use_dialog_box - && have_menus_p ()) - { - Lisp_Object pane, menu; - redisplay_preserve_echo_area (3); - pane = Fcons (Fcons (build_string ("Yes"), Qt), - Fcons (Fcons (build_string ("No"), Qnil), - Qnil)); - menu = Fcons (prompt, pane); - obj = Fx_popup_dialog (Qt, menu, Qnil); - answer = !NILP (obj); - break; - } -#endif /* HAVE_MENUS */ - cursor_in_echo_area = 1; - choose_minibuf_frame (); - - { - Lisp_Object pargs[3]; - - /* Colorize prompt according to `minibuffer-prompt' face. */ - pargs[0] = build_string ("%s(y or n) "); - pargs[1] = intern ("face"); - pargs[2] = intern ("minibuffer-prompt"); - args[0] = Fpropertize (3, pargs); - args[1] = xprompt; - Fmessage (2, args); - } - - if (minibuffer_auto_raise) - { - Lisp_Object mini_frame; - - mini_frame = WINDOW_FRAME (XWINDOW (minibuf_window)); - - Fraise_frame (mini_frame); - } - - temporarily_switch_to_single_kboard (SELECTED_FRAME ()); - obj = read_filtered_event (1, 0, 0, 0, Qnil); - cursor_in_echo_area = 0; - /* If we need to quit, quit with cursor_in_echo_area = 0. */ - QUIT; - - key = Fmake_vector (make_number (1), obj); - def = Flookup_key (map, key, Qt); - - if (EQ (def, intern ("skip"))) - { - answer = 0; - break; - } - else if (EQ (def, intern ("act"))) - { - answer = 1; - break; - } - else if (EQ (def, intern ("recenter"))) - { - Frecenter (Qnil); - xprompt = prompt; - continue; - } - else if (EQ (def, intern ("quit"))) - Vquit_flag = Qt; - /* We want to exit this command for exit-prefix, - and this is the only way to do it. */ - else if (EQ (def, intern ("exit-prefix"))) - Vquit_flag = Qt; - - QUIT; - - /* If we don't clear this, then the next call to read_char will - return quit_char again, and we'll enter an infinite loop. */ - Vquit_flag = Qnil; - - Fding (Qnil); - Fdiscard_input (); - if (EQ (xprompt, prompt)) - { - args[0] = build_string ("Please answer y or n. "); - args[1] = prompt; - xprompt = Fconcat (2, args); - } - } - UNGCPRO; - - if (! noninteractive) - { - cursor_in_echo_area = -1; - message_with_string (answer ? "%s(y or n) y" : "%s(y or n) n", - xprompt, 0); - } - - unbind_to (count, Qnil); - return answer ? Qt : Qnil; -} -\f /* This is how C code calls `yes-or-no-p' and allows the user to redefined it. @@ -5057,7 +4917,6 @@ defsubr (&Smapcar); defsubr (&Smapc); defsubr (&Smapconcat); - defsubr (&Sy_or_n_p); defsubr (&Syes_or_no_p); defsubr (&Sload_average); defsubr (&Sfeaturep); === modified file 'src/lisp.h' --- src/lisp.h 2010-09-10 23:24:48 +0000 +++ src/lisp.h 2010-09-11 14:09:41 +0000 @@ -2586,7 +2586,6 @@ EXFUN (Fnconc, MANY); EXFUN (Fmapcar, 2); EXFUN (Fmapconcat, 3); -EXFUN (Fy_or_n_p, 1); extern Lisp_Object do_yes_or_no_p (Lisp_Object); EXFUN (Frequire, 3); EXFUN (Fprovide, 2); ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6758: 23.2; xterm.el: please provide an option to not discard input in terminal-init-xterm 2010-08-24 0:48 ` Jim Paris 2010-09-11 14:08 ` Stefan Monnier 2010-09-11 14:59 ` Stefan Monnier @ 2013-03-11 14:12 ` Stefan Monnier 2 siblings, 0 replies; 15+ messages in thread From: Stefan Monnier @ 2013-03-11 14:12 UTC (permalink / raw) To: Jim Paris; +Cc: 6758-done, Johan Bockgård > Any thoughts on this patch? I installed a similar patch (tho rewritten based on the latest version of the code), except that it only uses your asynchronous approach if there's pending input. This way, the old synchronous method is still used in "most" cases and the new riskier approach is only used when we would otherwise have had to discard-input. Thank you for your help, Stefan ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6758: 23.2; xterm.el: please provide an option to not discard input in terminal-init-xterm 2010-07-29 20:15 bug#6758: 23.2; xterm.el: please provide an option to not discard input in terminal-init-xterm Jim Paris 2010-08-01 23:03 ` Stefan Monnier @ 2012-06-17 5:28 ` Chong Yidong 2012-06-19 4:03 ` bug#6758: So what do I need to do to keep emacs from eating my typeahead? Karl O. Pinc 2 siblings, 0 replies; 15+ messages in thread From: Chong Yidong @ 2012-06-17 5:28 UTC (permalink / raw) To: Jim Paris; +Cc: 6758 Jim Paris <jim@jtan.com> writes: > Since upgrading to emacs-23, the terminal-init-xterm function in > term/xterm.el performs a "discard-input" followed by a couple of xterm > queries. > > Can an option be provided to disable these probes? Emacs 24.1 has `xterm-extra-capabilities' for this. Closing. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6758: So what do I need to do to keep emacs from eating my typeahead? 2010-07-29 20:15 bug#6758: 23.2; xterm.el: please provide an option to not discard input in terminal-init-xterm Jim Paris 2010-08-01 23:03 ` Stefan Monnier 2012-06-17 5:28 ` Chong Yidong @ 2012-06-19 4:03 ` Karl O. Pinc 2012-06-19 7:51 ` Glenn Morris 2 siblings, 1 reply; 15+ messages in thread From: Karl O. Pinc @ 2012-06-19 4:03 UTC (permalink / raw) To: 6758, Jim Paris Hi, Thanks for fixing this, but I'm left unclear on what I would need to do to keep emacs from discarding my typeahead on startup. (Bug report #8482, merged with bug #6758.) I'll also have to get a new emacs (24.1), which might be why this is not clear. Sorry if this is the case, but I remain nervous that the solution will be obvious; `xterm-extra-capabilities' does not scream out to me as something that fixes a problem with typeahead. Thanks again for your work. Karl <kop@meme.com> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#6758: So what do I need to do to keep emacs from eating my typeahead? 2012-06-19 4:03 ` bug#6758: So what do I need to do to keep emacs from eating my typeahead? Karl O. Pinc @ 2012-06-19 7:51 ` Glenn Morris 0 siblings, 0 replies; 15+ messages in thread From: Glenn Morris @ 2012-06-19 7:51 UTC (permalink / raw) To: Karl O. Pinc; +Cc: 6758 "Karl O. Pinc" wrote: > Thanks for fixing this, but I'm left unclear on what I would need to > do to keep emacs from discarding my typeahead on startup. (Bug report > #8482, merged with bug #6758.) Set xterm-extra-capabilities to a value other than `check' (the default). See that variable's documentation (in term/xterm.el) for more details. Eg you may set it to nil. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2013-03-11 14:12 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-07-29 20:15 bug#6758: 23.2; xterm.el: please provide an option to not discard input in terminal-init-xterm Jim Paris 2010-08-01 23:03 ` Stefan Monnier 2010-08-02 20:38 ` Johan Bockgård 2010-08-02 20:59 ` Jim Paris 2010-08-02 21:27 ` Andreas Schwab 2010-08-02 21:36 ` Jim Paris 2010-08-02 22:21 ` Stefan Monnier 2010-08-03 20:14 ` Jim Paris 2010-08-24 0:48 ` Jim Paris 2010-09-11 14:08 ` Stefan Monnier 2010-09-11 14:59 ` Stefan Monnier 2013-03-11 14:12 ` Stefan Monnier 2012-06-17 5:28 ` Chong Yidong 2012-06-19 4:03 ` bug#6758: So what do I need to do to keep emacs from eating my typeahead? Karl O. Pinc 2012-06-19 7:51 ` Glenn Morris
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).