* 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
* 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
[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
@ 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
* 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-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
* 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 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-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: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 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-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
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.