* Re: Emacs 23.1 flushes stdin on startup @ 2009-08-05 15:42 David F. Skoll 0 siblings, 0 replies; 21+ messages in thread From: David F. Skoll @ 2009-08-05 15:42 UTC (permalink / raw) To: help-gnu-emacs Johan Bockgard wrote: > It's caused by the xterm init code (info "(elisp) Terminal-Specific") > for finding out if the terminal is modern enough to support the > `modifyOtherKeys' feature; see term/xterm.el. ... > There's no simple knob, unfortunately, but there's always some way. :-( Thanks for your explanation. I'll poke around to see if I can find a nice way to make it work. Regards, David. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Emacs 23.1 flushes stdin on startup @ 2009-08-04 20:16 David F. Skoll 2009-08-04 22:33 ` Johan Bockgård [not found] ` <mailman.3892.1249425263.2239.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 21+ messages in thread From: David F. Skoll @ 2009-08-04 20:16 UTC (permalink / raw) To: help-gnu-emacs Hi, I've noticed a behavior change in 23.1 that doesn't seem to be documented: If I start Emacs in text mode (eg: "emacs -nw") and type stuff before Emacs has started up, the stuff I type is lost. Version 22 would not flush the input, and my pre-startup stuff would appear in the buffer. I really miss the old behavior. Is there any way to convince Emacs 23.1 not to flush stdin on startup? Regards, David. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Emacs 23.1 flushes stdin on startup 2009-08-04 20:16 David F. Skoll @ 2009-08-04 22:33 ` Johan Bockgård 2009-08-05 6:20 ` Kevin Rodgers [not found] ` <mailman.3892.1249425263.2239.help-gnu-emacs@gnu.org> 1 sibling, 1 reply; 21+ messages in thread From: Johan Bockgård @ 2009-08-04 22:33 UTC (permalink / raw) To: help-gnu-emacs "David F. Skoll" <dfs@roaringpenguin.com> writes: > I've noticed a behavior change in 23.1 that doesn't seem to be documented: > If I start Emacs in text mode (eg: "emacs -nw") and type stuff before > Emacs has started up, the stuff I type is lost. Version 22 would not > flush the input, and my pre-startup stuff would appear in the buffer. It's caused by the xterm init code (info "(elisp) Terminal-Specific") for finding out if the terminal is modern enough to support the `modifyOtherKeys' feature; see term/xterm.el. [...] ;; 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") > I really miss the old behavior. Is there any way to convince Emacs 23.1 > not to flush stdin on startup? There's no simple knob, unfortunately, but there's always some way. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Emacs 23.1 flushes stdin on startup 2009-08-04 22:33 ` Johan Bockgård @ 2009-08-05 6:20 ` Kevin Rodgers 0 siblings, 0 replies; 21+ messages in thread From: Kevin Rodgers @ 2009-08-05 6:20 UTC (permalink / raw) To: help-gnu-emacs Johan Bockgård wrote: > "David F. Skoll" <dfs@roaringpenguin.com> writes: > >> I've noticed a behavior change in 23.1 that doesn't seem to be documented: >> If I start Emacs in text mode (eg: "emacs -nw") and type stuff before >> Emacs has started up, the stuff I type is lost. Version 22 would not >> flush the input, and my pre-startup stuff would appear in the buffer. > > It's caused by the xterm init code (info "(elisp) Terminal-Specific") > for finding out if the terminal is modern enough to support the > `modifyOtherKeys' feature; see term/xterm.el. > > [...] > ;; 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") > >> I really miss the old behavior. Is there any way to convince Emacs 23.1 >> not to flush stdin on startup? > > There's no simple knob, unfortunately, but there's always some way. Too bad discard-input doesn't return the discarded events, so that they could be re-read via unread-command-events. -- Kevin Rodgers Denver, Colorado, USA ^ permalink raw reply [flat|nested] 21+ messages in thread
[parent not found: <mailman.3892.1249425263.2239.help-gnu-emacs@gnu.org>]
* Re: Emacs 23.1 flushes stdin on startup [not found] ` <mailman.3892.1249425263.2239.help-gnu-emacs@gnu.org> @ 2009-08-05 14:00 ` Ted Zlatanov 2009-08-05 14:00 ` Ted Zlatanov 1 sibling, 0 replies; 21+ messages in thread From: Ted Zlatanov @ 2009-08-05 14:00 UTC (permalink / raw) To: help-gnu-emacs; +Cc: Emacs Development On Wed, 05 Aug 2009 00:33:56 +0200 bojohan+news@dd.chalmers.se (Johan Bockgård) wrote: JB> "David F. Skoll" <dfs@roaringpenguin.com> writes: >> I've noticed a behavior change in 23.1 that doesn't seem to be documented: >> If I start Emacs in text mode (eg: "emacs -nw") and type stuff before >> Emacs has started up, the stuff I type is lost. Version 22 would not >> flush the input, and my pre-startup stuff would appear in the buffer. JB> It's caused by the xterm init code (info "(elisp) Terminal-Specific") JB> for finding out if the terminal is modern enough to support the JB> `modifyOtherKeys' feature; see term/xterm.el. JB> [...] JB> ;; Pending input can be mistakenly returned by the calls to JB> ;; read-event below. Discard it. JB> (discard-input) JB> ;; Try to find out the type of terminal by sending a "Secondary JB> ;; Device Attributes (DA)" query. JB> (send-string-to-terminal "\e[>0c") >> I really miss the old behavior. Is there any way to convince Emacs 23.1 >> not to flush stdin on startup? JB> There's no simple knob, unfortunately, but there's always some way. How about adding a variable xterm-modify-other-keys-supported with values t, nil, and 'check? It would make the startup slightly faster, too. Small untested patch attached to illustrate. Ted Index: xterm.el =================================================================== RCS file: /sources/emacs/emacs/lisp/term/xterm.el,v retrieving revision 1.62 diff -c -r1.62 xterm.el *** xterm.el 5 Jan 2009 03:23:59 -0000 1.62 --- xterm.el 5 Aug 2009 13:59:26 -0000 *************** *** 25,30 **** --- 25,36 ---- ;;; Code: + (defcustom xterm-modify-other-keys-supported 'check + "Whether the XTerm supports modifyOtherKeys." + :type '(choice (const :tag "No" nil) + (const :tag "Yes" t) + (const :tag "Check" check))) + (defvar xterm-function-map (let ((map (make-sparse-keymap))) *************** *** 470,515 **** ;; 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)) ! ;; 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) ! ;; NUMBER2 is the xterm version number, look for something ! ;; greater than 216, the version when modifyOtherKeys was ! ;; introduced. ! (when (>= (string-to-number ! (substring str (match-beginning 1) (match-end 1))) 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)))))) (run-hooks 'terminal-init-xterm-hook)) ;; Set up colors, for those versions of xterm that support it. (defvar xterm-standard-colors ;; The names in the comments taken from XTerm-col.ad in the xterm --- 476,529 ---- ;; C-. C-, etc. ;; To do that we need to find out if the current terminal supports ;; modifyOtherKeys. At this time only xterm does. ! (when xterm-modify-other-keys-supported ! (cond ! ((eq xterm-modify-other-keys-supported 'check) ! (let ((coding-system-for-read 'binary) ! (chr nil) ! (str nil)) ! ;; 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) ! ;; NUMBER2 is the xterm version number, look for something ! ;; greater than 216, the version when modifyOtherKeys was ! ;; introduced. ! (when (>= (string-to-number ! (substring str (match-beginning 1) (match-end 1))) 216) ! (terminal-init-xterm-modify-other-keys))))))) ! (t (terminal-init-xterm-modify-other-keys)))) (run-hooks 'terminal-init-xterm-hook)) + (defun terminal-init-xterm-modify-other-keys () + "Terminal initialization for xterm's modifyOtherKeys support." + ;; 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)) + ;; Set up colors, for those versions of xterm that support it. (defvar xterm-standard-colors ;; The names in the comments taken from XTerm-col.ad in the xterm ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Emacs 23.1 flushes stdin on startup [not found] ` <mailman.3892.1249425263.2239.help-gnu-emacs@gnu.org> 2009-08-05 14:00 ` Ted Zlatanov @ 2009-08-05 14:00 ` Ted Zlatanov 2009-08-06 16:33 ` Stefan Monnier ` (2 more replies) 1 sibling, 3 replies; 21+ messages in thread From: Ted Zlatanov @ 2009-08-05 14:00 UTC (permalink / raw) Cc: Emacs Development The following message is a courtesy copy of an article that has been posted to gnu.emacs.help as well. On Wed, 05 Aug 2009 00:33:56 +0200 bojohan+news@dd.chalmers.se (Johan Bockgård) wrote: JB> "David F. Skoll" <dfs@roaringpenguin.com> writes: >> I've noticed a behavior change in 23.1 that doesn't seem to be documented: >> If I start Emacs in text mode (eg: "emacs -nw") and type stuff before >> Emacs has started up, the stuff I type is lost. Version 22 would not >> flush the input, and my pre-startup stuff would appear in the buffer. JB> It's caused by the xterm init code (info "(elisp) Terminal-Specific") JB> for finding out if the terminal is modern enough to support the JB> `modifyOtherKeys' feature; see term/xterm.el. JB> [...] JB> ;; Pending input can be mistakenly returned by the calls to JB> ;; read-event below. Discard it. JB> (discard-input) JB> ;; Try to find out the type of terminal by sending a "Secondary JB> ;; Device Attributes (DA)" query. JB> (send-string-to-terminal "\e[>0c") >> I really miss the old behavior. Is there any way to convince Emacs 23.1 >> not to flush stdin on startup? JB> There's no simple knob, unfortunately, but there's always some way. How about adding a variable xterm-modify-other-keys-supported with values t, nil, and 'check? It would make the startup slightly faster, too. Small untested patch attached to illustrate. Ted Index: xterm.el =================================================================== RCS file: /sources/emacs/emacs/lisp/term/xterm.el,v retrieving revision 1.62 diff -c -r1.62 xterm.el *** xterm.el 5 Jan 2009 03:23:59 -0000 1.62 --- xterm.el 5 Aug 2009 13:59:26 -0000 *************** *** 25,30 **** --- 25,36 ---- ;;; Code: + (defcustom xterm-modify-other-keys-supported 'check + "Whether the XTerm supports modifyOtherKeys." + :type '(choice (const :tag "No" nil) + (const :tag "Yes" t) + (const :tag "Check" check))) + (defvar xterm-function-map (let ((map (make-sparse-keymap))) *************** *** 470,515 **** ;; 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)) ! ;; 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) ! ;; NUMBER2 is the xterm version number, look for something ! ;; greater than 216, the version when modifyOtherKeys was ! ;; introduced. ! (when (>= (string-to-number ! (substring str (match-beginning 1) (match-end 1))) 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)))))) (run-hooks 'terminal-init-xterm-hook)) ;; Set up colors, for those versions of xterm that support it. (defvar xterm-standard-colors ;; The names in the comments taken from XTerm-col.ad in the xterm --- 476,529 ---- ;; C-. C-, etc. ;; To do that we need to find out if the current terminal supports ;; modifyOtherKeys. At this time only xterm does. ! (when xterm-modify-other-keys-supported ! (cond ! ((eq xterm-modify-other-keys-supported 'check) ! (let ((coding-system-for-read 'binary) ! (chr nil) ! (str nil)) ! ;; 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) ! ;; NUMBER2 is the xterm version number, look for something ! ;; greater than 216, the version when modifyOtherKeys was ! ;; introduced. ! (when (>= (string-to-number ! (substring str (match-beginning 1) (match-end 1))) 216) ! (terminal-init-xterm-modify-other-keys))))))) ! (t (terminal-init-xterm-modify-other-keys)))) (run-hooks 'terminal-init-xterm-hook)) + (defun terminal-init-xterm-modify-other-keys () + "Terminal initialization for xterm's modifyOtherKeys support." + ;; 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)) + ;; Set up colors, for those versions of xterm that support it. (defvar xterm-standard-colors ;; The names in the comments taken from XTerm-col.ad in the xterm ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Emacs 23.1 flushes stdin on startup 2009-08-05 14:00 ` Ted Zlatanov @ 2009-08-06 16:33 ` Stefan Monnier 2009-08-11 20:14 ` Ted Zlatanov 2009-08-06 16:35 ` Stefan Monnier 2009-08-07 21:02 ` Johan Bockgård 2 siblings, 1 reply; 21+ messages in thread From: Stefan Monnier @ 2009-08-06 16:33 UTC (permalink / raw) To: Ted Zlatanov; +Cc: Emacs Development > How about adding a variable xterm-modify-other-keys-supported with > values t, nil, and 'check? It would make the startup slightly > faster, too. Sounds OK. > ! (when xterm-modify-other-keys-supported > ! (cond > ! ((eq xterm-modify-other-keys-supported 'check) Please merge the when and the cond into a single cond (which will give meaning to this `cond', since as it stands it only has two arms and could hence as well use `if'). Stefan ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Emacs 23.1 flushes stdin on startup 2009-08-06 16:33 ` Stefan Monnier @ 2009-08-11 20:14 ` Ted Zlatanov 2009-08-28 14:21 ` Ted Zlatanov 0 siblings, 1 reply; 21+ messages in thread From: Ted Zlatanov @ 2009-08-11 20:14 UTC (permalink / raw) To: emacs-devel On Thu, 06 Aug 2009 12:33:47 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: SM> Please merge the when and the cond into a single cond (which will give SM> meaning to this `cond', since as it stands it only has two arms and SM> could hence as well use `if'). On Thu, 06 Aug 2009 12:35:05 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: SM> One more thing: terminal-init-<foo> should only be used for "the setup SM> code for terminal FOO". Since there aren't any terminal named SM> "xterm-modify-other-keys" and this function doesn't treat them, better SM> use some other name, such as just `xterm-modify-other-keys'. OK, I did both. On Fri, 07 Aug 2009 23:02:03 +0200 bojohan+news@dd.chalmers.se (Johan Bockgård) wrote: JB> Yes. I just don't like the name. I would set this new variable to nil, JB> but not because the feature is not supported in my terminal, but rather JB> that it is already enabled there without having Emacs turn it on. I don't know how to choose a better name, sorry. Feel free to suggest alternatives. Another version lies below. Let me know if it looks OK. My change is minor but I may have missed something. Ted Index: xterm.el =================================================================== RCS file: /sources/emacs/emacs/lisp/term/xterm.el,v retrieving revision 1.62 diff -c -r1.62 xterm.el *** xterm.el 5 Jan 2009 03:23:59 -0000 1.62 --- xterm.el 11 Aug 2009 20:11:29 -0000 *************** *** 25,30 **** --- 25,36 ---- ;;; Code: + (defcustom xterm-supported-modify-other-keys 'check + "Whether the XTerm supports modifyOtherKeys." + :type '(choice (const :tag "No" nil) + (const :tag "Yes" t) + (const :tag "Check" check))) + (defvar xterm-function-map (let ((map (make-sparse-keymap))) *************** *** 470,515 **** ;; 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)) ! ;; 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) ! ;; NUMBER2 is the xterm version number, look for something ! ;; greater than 216, the version when modifyOtherKeys was ! ;; introduced. ! (when (>= (string-to-number ! (substring str (match-beginning 1) (match-end 1))) 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)))))) (run-hooks 'terminal-init-xterm-hook)) ;; Set up colors, for those versions of xterm that support it. (defvar xterm-standard-colors ;; The names in the comments taken from XTerm-col.ad in the xterm --- 476,528 ---- ;; C-. C-, etc. ;; To do that we need to find out if the current terminal supports ;; modifyOtherKeys. At this time only xterm does. ! (cond ! ((eq xterm-supported-modify-other-keys 'check) ! (let ((coding-system-for-read 'binary) ! (chr nil) ! (str nil)) ! ;; 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) ! ;; NUMBER2 is the xterm version number, look for something ! ;; greater than 216, the version when modifyOtherKeys was ! ;; introduced. ! (when (>= (string-to-number ! (substring str (match-beginning 1) (match-end 1))) 216) ! (xterm-modify-other-keys))))))) ! (xterm-supported-modify-other-keys (xterm-modify-other-keys))) (run-hooks 'terminal-init-xterm-hook)) + (defun xterm-modify-other-keys () + "Terminal initialization for xterm's modifyOtherKeys support." + ;; 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)) + ;; Set up colors, for those versions of xterm that support it. (defvar xterm-standard-colors ;; The names in the comments taken from XTerm-col.ad in the xterm ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Emacs 23.1 flushes stdin on startup 2009-08-11 20:14 ` Ted Zlatanov @ 2009-08-28 14:21 ` Ted Zlatanov 2009-08-28 16:27 ` Ulrich Mueller 2009-08-28 16:42 ` Stefan Monnier 0 siblings, 2 replies; 21+ messages in thread From: Ted Zlatanov @ 2009-08-28 14:21 UTC (permalink / raw) To: emacs-devel On Tue, 11 Aug 2009 15:14:11 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: TZ> I don't know how to choose a better name, sorry. Feel free to suggest TZ> alternatives. TZ> Another version lies below. Let me know if it looks OK. My change is TZ> minor but I may have missed something. I haven't seen a response from Stefan (about the code rewrite) or Johan (about the naming). Can you please let me know if the patch is OK? Thanks Ted ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Emacs 23.1 flushes stdin on startup 2009-08-28 14:21 ` Ted Zlatanov @ 2009-08-28 16:27 ` Ulrich Mueller 2009-08-29 2:19 ` Ted Zlatanov 2009-08-28 16:42 ` Stefan Monnier 1 sibling, 1 reply; 21+ messages in thread From: Ulrich Mueller @ 2009-08-28 16:27 UTC (permalink / raw) To: Ted Zlatanov; +Cc: emacs-devel >>>>> On Fri, 28 Aug 2009, Ted Zlatanov wrote: > I haven't seen a response from Stefan (about the code rewrite) or Johan > (about the naming). Can you please let me know if the patch is OK? Sorry, but introducing a config variable to work around this problem looks broken to me. Isn't there any better solution? For example, can't the pending input be saved and stuffed back into the input buffer, instead of discarding it? Ulrich ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Emacs 23.1 flushes stdin on startup 2009-08-28 16:27 ` Ulrich Mueller @ 2009-08-29 2:19 ` Ted Zlatanov 2009-08-29 9:12 ` Ulrich Mueller 0 siblings, 1 reply; 21+ messages in thread From: Ted Zlatanov @ 2009-08-29 2:19 UTC (permalink / raw) To: Ulrich Mueller; +Cc: emacs-devel On Fri, 28 Aug 2009 18:27:42 +0200 Ulrich Mueller <ulm@gentoo.org> wrote: >>>>>> On Fri, 28 Aug 2009, Ted Zlatanov wrote: >> I haven't seen a response from Stefan (about the code rewrite) or Johan >> (about the naming). Can you please let me know if the patch is OK? UM> Sorry, but introducing a config variable to work around this problem UM> looks broken to me. UM> Isn't there any better solution? For example, can't the pending input UM> be saved and stuffed back into the input buffer, instead of discarding UM> it? Emacs already tries to DTRT so this overrides it when the user wants or it can't guess accurately. See http://article.gmane.org/gmane.emacs.help/66789 for the original post. I think (from looking at the code) that doing it without a variable would require much more complicated code, and the benefit would be small. I could certainly be wrong, though. Ted ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Emacs 23.1 flushes stdin on startup 2009-08-29 2:19 ` Ted Zlatanov @ 2009-08-29 9:12 ` Ulrich Mueller 2009-08-29 14:19 ` Chong Yidong 0 siblings, 1 reply; 21+ messages in thread From: Ulrich Mueller @ 2009-08-29 9:12 UTC (permalink / raw) To: Ted Zlatanov; +Cc: emacs-devel >>>>> On Fri, 28 Aug 2009, Ted Zlatanov wrote: UM> Isn't there any better solution? For example, can't the pending input UM> be saved and stuffed back into the input buffer, instead of discarding UM> it? > Emacs already tries to DTRT so this overrides it when the user wants > or it can't guess accurately. > See http://article.gmane.org/gmane.emacs.help/66789 for the original > post. I had read that post. The question is if discarding the input is really necessary, or if it could be saved somehow? > I think (from looking at the code) that doing it without a variable > would require much more complicated code, and the benefit would be > small. The benefit would be that pending input wasn't discarded in the default configuration. Ulrich ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Emacs 23.1 flushes stdin on startup 2009-08-29 9:12 ` Ulrich Mueller @ 2009-08-29 14:19 ` Chong Yidong 0 siblings, 0 replies; 21+ messages in thread From: Chong Yidong @ 2009-08-29 14:19 UTC (permalink / raw) To: Ulrich Mueller; +Cc: Ted Zlatanov, emacs-devel Ulrich Mueller <ulm@gentoo.org> writes: > I had read that post. The question is if discarding the input is > really necessary, or if it could be saved somehow? This will involve either "reverse keyboard translation", or delaying keyboard translation till after the terminal initialization is complete (which may not be trivial for the multi-tty case). When I looked at the problem a while back, my impression was that it's not worth the effort. But if you'd like to make the attempt, please go ahead and try. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Emacs 23.1 flushes stdin on startup 2009-08-28 14:21 ` Ted Zlatanov 2009-08-28 16:27 ` Ulrich Mueller @ 2009-08-28 16:42 ` Stefan Monnier 2009-08-28 18:09 ` Dan Nicolaescu 1 sibling, 1 reply; 21+ messages in thread From: Stefan Monnier @ 2009-08-28 16:42 UTC (permalink / raw) To: Ted Zlatanov; +Cc: emacs-devel > On Tue, 11 Aug 2009 15:14:11 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: TZ> I don't know how to choose a better name, sorry. Feel free to suggest TZ> alternatives. TZ> Another version lies below. Let me know if it looks OK. My change is TZ> minor but I may have missed something. > I haven't seen a response from Stefan (about the code rewrite) or Johan > (about the naming). Can you please let me know if the patch is OK? I replied about the name, proposing `xterm-enable-modify-other-keys' with docstring "Whether or not to activate modifyOtherKeys in xterm" and documenting nil, t and check as valid values. The code change itself looks fine, Stefan ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Emacs 23.1 flushes stdin on startup 2009-08-28 16:42 ` Stefan Monnier @ 2009-08-28 18:09 ` Dan Nicolaescu 2009-08-29 0:48 ` Stefan Monnier 0 siblings, 1 reply; 21+ messages in thread From: Dan Nicolaescu @ 2009-08-28 18:09 UTC (permalink / raw) To: Stefan Monnier; +Cc: Ted Zlatanov, emacs-devel Stefan Monnier <monnier@IRO.UMontreal.CA> writes: > > On Tue, 11 Aug 2009 15:14:11 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: > TZ> I don't know how to choose a better name, sorry. Feel free to suggest > TZ> alternatives. > > TZ> Another version lies below. Let me know if it looks OK. My change is > TZ> minor but I may have missed something. > > > I haven't seen a response from Stefan (about the code rewrite) or Johan > > (about the naming). Can you please let me know if the patch is OK? > > I replied about the name, proposing `xterm-enable-modify-other-keys' > with docstring "Whether or not to activate modifyOtherKeys in xterm" and > documenting nil, t and check as valid values. > > The code change itself looks fine, Please see bug#4234, I have a patch there to allow emacs to read the background color from xterm so that it can set the correct background-mode (and not just default to 'light). When that code is allowed to be checked in, `xterm-enable-modify-other-keys' will not be appropriate anymore. Maybe `xterm-enable-terminal-query' ? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Emacs 23.1 flushes stdin on startup 2009-08-28 18:09 ` Dan Nicolaescu @ 2009-08-29 0:48 ` Stefan Monnier 2009-08-29 2:07 ` Ted Zlatanov 2009-08-30 6:10 ` Dan Nicolaescu 0 siblings, 2 replies; 21+ messages in thread From: Stefan Monnier @ 2009-08-29 0:48 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Ted Zlatanov, emacs-devel > Please see bug#4234, I have a patch there to allow emacs to read the > background color from xterm so that it can set the correct > background-mode (and not just default to 'light). > When that code is allowed to be checked in, > `xterm-enable-modify-other-keys' will not be appropriate anymore. > Maybe `xterm-enable-terminal-query' ? The problem is that we don't want to control whether we query or not, but also the decision we take based on the (expected) result. So maybe your code should use a similar xterm-background-mode which can be set to `dark', `light' or `check'. Stefan ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Emacs 23.1 flushes stdin on startup 2009-08-29 0:48 ` Stefan Monnier @ 2009-08-29 2:07 ` Ted Zlatanov 2009-08-29 4:10 ` Dan Nicolaescu 2009-08-30 6:10 ` Dan Nicolaescu 1 sibling, 1 reply; 21+ messages in thread From: Ted Zlatanov @ 2009-08-29 2:07 UTC (permalink / raw) To: Stefan Monnier; +Cc: Dan Nicolaescu, emacs-devel On Fri, 28 Aug 2009 20:48:40 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: >> Please see bug#4234, I have a patch there to allow emacs to read the >> background color from xterm so that it can set the correct >> background-mode (and not just default to 'light). >> When that code is allowed to be checked in, >> `xterm-enable-modify-other-keys' will not be appropriate anymore. >> Maybe `xterm-enable-terminal-query' ? SM> The problem is that we don't want to control whether we query or not, SM> but also the decision we take based on the (expected) result. SM> So maybe your code should use a similar xterm-background-mode which can SM> be set to `dark', `light' or `check'. Dan, since you are driving #4234, do you want to just fold my patch into yours and change it to be consistent with your naming, whatever it is when you and Stefan come to agreement? It would certainly be easier since my side is done and not critical for quick inclusion. Thanks Ted ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Emacs 23.1 flushes stdin on startup 2009-08-29 2:07 ` Ted Zlatanov @ 2009-08-29 4:10 ` Dan Nicolaescu 0 siblings, 0 replies; 21+ messages in thread From: Dan Nicolaescu @ 2009-08-29 4:10 UTC (permalink / raw) To: Ted Zlatanov; +Cc: Stefan Monnier, emacs-devel Ted Zlatanov <tzz@lifelogs.com> writes: > On Fri, 28 Aug 2009 20:48:40 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: > > >> Please see bug#4234, I have a patch there to allow emacs to read the > >> background color from xterm so that it can set the correct > >> background-mode (and not just default to 'light). > >> When that code is allowed to be checked in, > >> `xterm-enable-modify-other-keys' will not be appropriate anymore. > >> Maybe `xterm-enable-terminal-query' ? > > SM> The problem is that we don't want to control whether we query or not, > SM> but also the decision we take based on the (expected) result. > SM> So maybe your code should use a similar xterm-background-mode which can > SM> be set to `dark', `light' or `check'. > > Dan, since you are driving #4234, do you want to just fold my patch into > yours and change it to be consistent with your naming, whatever it is > when you and Stefan come to agreement? It would certainly be easier > since my side is done and not critical for quick inclusion. Given that your side is done, and from what Stefan I need to do add a different variable to control what I need anyway, I would not want to hold you back. I'll adapt my change to whatever you check in. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Emacs 23.1 flushes stdin on startup 2009-08-29 0:48 ` Stefan Monnier 2009-08-29 2:07 ` Ted Zlatanov @ 2009-08-30 6:10 ` Dan Nicolaescu 1 sibling, 0 replies; 21+ messages in thread From: Dan Nicolaescu @ 2009-08-30 6:10 UTC (permalink / raw) To: Stefan Monnier; +Cc: Ted Zlatanov, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > > Please see bug#4234, I have a patch there to allow emacs to read the > > background color from xterm so that it can set the correct > > background-mode (and not just default to 'light). > > When that code is allowed to be checked in, > > `xterm-enable-modify-other-keys' will not be appropriate anymore. > > Maybe `xterm-enable-terminal-query' ? > > The problem is that we don't want to control whether we query or not, > but also the decision we take based on the (expected) result. > So maybe your code should use a similar xterm-background-mode which can > be set to `dark', `light' or `check'. Sounds like a good idea. I'll do that after Ted's patch is checked in. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Emacs 23.1 flushes stdin on startup 2009-08-05 14:00 ` Ted Zlatanov 2009-08-06 16:33 ` Stefan Monnier @ 2009-08-06 16:35 ` Stefan Monnier 2009-08-07 21:02 ` Johan Bockgård 2 siblings, 0 replies; 21+ messages in thread From: Stefan Monnier @ 2009-08-06 16:35 UTC (permalink / raw) To: Ted Zlatanov; +Cc: Emacs Development > + (defun terminal-init-xterm-modify-other-keys () One more thing: terminal-init-<foo> should only be used for "the setup code for terminal FOO". Since there aren't any terminal named "xterm-modify-other-keys" and this function doesn't treat them, better use some other name, such as just `xterm-modify-other-keys'. Stefan ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Emacs 23.1 flushes stdin on startup 2009-08-05 14:00 ` Ted Zlatanov 2009-08-06 16:33 ` Stefan Monnier 2009-08-06 16:35 ` Stefan Monnier @ 2009-08-07 21:02 ` Johan Bockgård 2 siblings, 0 replies; 21+ messages in thread From: Johan Bockgård @ 2009-08-07 21:02 UTC (permalink / raw) To: emacs-devel Ted Zlatanov <tzz@lifelogs.com> writes: > How about adding a variable xterm-modify-other-keys-supported with > values t, nil, and 'check? It would make the startup slightly faster, > too. Yes. I just don't like the name. I would set this new variable to nil, but not because the feature is not supported in my terminal, but rather that it is already enabled there without having Emacs turn it on. ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2009-08-30 6:10 UTC | newest] Thread overview: 21+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-08-05 15:42 Emacs 23.1 flushes stdin on startup David F. Skoll -- strict thread matches above, loose matches on Subject: below -- 2009-08-04 20:16 David F. Skoll 2009-08-04 22:33 ` Johan Bockgård 2009-08-05 6:20 ` Kevin Rodgers [not found] ` <mailman.3892.1249425263.2239.help-gnu-emacs@gnu.org> 2009-08-05 14:00 ` Ted Zlatanov 2009-08-05 14:00 ` Ted Zlatanov 2009-08-06 16:33 ` Stefan Monnier 2009-08-11 20:14 ` Ted Zlatanov 2009-08-28 14:21 ` Ted Zlatanov 2009-08-28 16:27 ` Ulrich Mueller 2009-08-29 2:19 ` Ted Zlatanov 2009-08-29 9:12 ` Ulrich Mueller 2009-08-29 14:19 ` Chong Yidong 2009-08-28 16:42 ` Stefan Monnier 2009-08-28 18:09 ` Dan Nicolaescu 2009-08-29 0:48 ` Stefan Monnier 2009-08-29 2:07 ` Ted Zlatanov 2009-08-29 4:10 ` Dan Nicolaescu 2009-08-30 6:10 ` Dan Nicolaescu 2009-08-06 16:35 ` Stefan Monnier 2009-08-07 21:02 ` Johan Bockgård
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.