Re: Emacs 23.1 flushes stdin on startup

Re: Emacs 23.1 flushes stdin on startup

[Ted Zlatanov]

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

Re: Emacs 23.1 flushes stdin on startup

[Stefan Monnier]

> 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

Re: Emacs 23.1 flushes stdin on startup

[Stefan Monnier]

> + (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

Re: Emacs 23.1 flushes stdin on startup

[Johan Bockgård]

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.

Re: Emacs 23.1 flushes stdin on startup

[Ted Zlatanov]

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

Re: Emacs 23.1 flushes stdin on startup

[Ted Zlatanov]

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

Re: Emacs 23.1 flushes stdin on startup

[Ulrich Mueller]

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

Re: Emacs 23.1 flushes stdin on startup

[Stefan Monnier]

> 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

Re: Emacs 23.1 flushes stdin on startup

[Dan Nicolaescu]

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' ?

Re: Emacs 23.1 flushes stdin on startup

[Stefan Monnier]

> 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

Re: Emacs 23.1 flushes stdin on startup

[Ted Zlatanov]

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

Re: Emacs 23.1 flushes stdin on startup

[Ted Zlatanov]

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

Re: Emacs 23.1 flushes stdin on startup

[Dan Nicolaescu]

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.

Re: Emacs 23.1 flushes stdin on startup

[Ulrich Mueller]

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

Re: Emacs 23.1 flushes stdin on startup

[Chong Yidong]

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.

Re: Emacs 23.1 flushes stdin on startup

[Dan Nicolaescu]

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.