Emacs 23.1 flushes stdin on startup

Emacs 23.1 flushes stdin on startup

[David F. Skoll]

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.

Re: Emacs 23.1 flushes stdin on startup

[Johan Bockgård]

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

Re: Emacs 23.1 flushes stdin on startup

[Kevin Rodgers]

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

Re: Emacs 23.1 flushes stdin on startup

[Ted Zlatanov]

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

Re: Emacs 23.1 flushes stdin on startup

[David F. Skoll]

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.