GNU bug report logs - #14615
xterm--query results in slow -nw startup on some terminals

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 14615 in the body.
You can then email your comments to 14615 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #3 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: submit <at> debbugs.gnu.org
Subject: xterm--query results in slow -nw startup on some terminals
Date: Thu, 13 Jun 2013 19:36:21 -0400

Package: emacs
Version: 24.3.50

Current trunk on GNU/Linux.

emacs -Q -nw ./README

There is a noticeable delay (it feels like about 2 seconds) during
startup during which the scratch buffer is visible, before the README
file appears. There's plenty of time for me to hit ctrl-g, in which case
README is never visited. This does not happen in 24.3.

I imagine it is this change:
http://lists.gnu.org/archive/html/emacs-diffs/2013-03/msg00124.html

and the use of (read-event nil nil 2).

Reverting that change makes it fast again (but it doesn't work properly).
It seems to work fine with 24.3's xterm.el.

This is with TERM=xterm-vt220, using (the pretty old) aterm 0.4.2.
http://www.afterstep.org/aterm.php

There is no such delay with xterm or xfce4-terminal.

Maybe it's finally time for me to get a new terminal emulator...

Message #6 received at 14615 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 14615 <at> debbugs.gnu.org
Subject: Re: bug#14615: xterm--query results in slow -nw startup on some
 terminals
Date: Thu, 13 Jun 2013 20:26:59 -0400

> There is a noticeable delay (it feels like about 2 seconds) during
> startup during which the scratch buffer is visible, before the README
> file appears. There's plenty of time for me to hit ctrl-g, in which case
> README is never visited. This does not happen in 24.3.

> I imagine it is this change:
> http://lists.gnu.org/archive/html/emacs-diffs/2013-03/msg00124.html

Ironic, since this patch makes the code more asynchronous than before
(tho, apparently it somehow makes it more synchronous in your case).

> This is with TERM=xterm-vt220, using (the pretty old) aterm 0.4.2.
> http://www.afterstep.org/aterm.php
> There is no such delay with xterm or xfce4-terminal.

Can you show C-h l after such a slow startup?


        Stefan

Message #9 received at 14615 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 14615 <at> debbugs.gnu.org
Subject: Re: bug#14615: xterm--query results in slow -nw startup on some
 terminals
Date: Thu, 13 Jun 2013 20:34:28 -0400

Stefan Monnier wrote:

> Can you show C-h l after such a slow startup?

ESC [ ? 1 ; 2 c C-h l


Same result in 24.3, but not slow.

Message #12 received at 14615 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 14615 <at> debbugs.gnu.org
Subject: Re: bug#14615: xterm--query results in slow -nw startup on some
 terminals
Date: Thu, 13 Jun 2013 21:17:38 -0400

>> Can you show C-h l after such a slow startup?
> ESC [ ? 1 ; 2 c C-h l
> Same result in 24.3, but not slow.

Hmm... that looks harmless enough.

Could you add some `message's to xterm--query to see whether we take the
synchronous or the asynchronous route?

Also, can you try to set debug-on-quit and get a backtrace during the
2s wait?


        Stefan "who installed Debian's aterm, but whose aterm refuses to
                start, giving him a BadWindow error instead"

Message #15 received at 14615 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 14615 <at> debbugs.gnu.org
Subject: Re: bug#14615: xterm--query results in slow -nw startup on some
 terminals
Date: Thu, 13 Jun 2013 21:36:56 -0400

Stefan Monnier wrote:

> Could you add some `message's to xterm--query to see whether we take the
> synchronous or the asynchronous route?

Commenting out the

("\e[>" . xterm--version-handler)

makes it fast again.
Otherwise the slowness seems to be at this part:

(while (and (< i (length (car handler)))
     (let ((evt (read-event nil nil 2)))

When handler == ("\e[>" . xterm--version-handler), i = 0, read-event
takes 2 seconds to return nil.

> Also, can you try to set debug-on-quit and get a backtrace during the
> 2s wait?

Not informative:

Debugger entered--Lisp error: (quit)
  xterm--query("^[[>0c" (("^[[?" . xterm--version-handler) ("^[[>" . xterm--version-handler)))
  terminal-init-xterm()
  tty-run-terminal-initialization(#<frame F1 0xb8cbc0>)
  command-line()
  normal-top-level()

>         Stefan "who installed Debian's aterm, but whose aterm refuses to
>                 start, giving him a BadWindow error instead"

Mine is some ancient [1] self-compiled version on RHEL6.

[1] Hah, I just checked: installed 6.5 years ago.

Message #18 received at 14615 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 14615 <at> debbugs.gnu.org
Subject: Re: bug#14615: xterm--query results in slow -nw startup on some
 terminals
Date: Fri, 14 Jun 2013 03:38:41 -0400

echo -e "\e[>0c"
returns
^[[?1;2c  for aterm  (the Debian one runs fine for me and is also slow)
^[[>41;293;0c  for xterm
^[[>1;2802;0c  for xfce4-terminal

Here's the values of

  i (car handler) evt unread-command-events
followed by
  i (length (car handler)

for xterm / xfce4-terminal:

0 "^[[?" 27 nil
1 "^[[?" 91 nil
2 "^[[?" 62 nil
2 3
0 "^[[>" 27 (91 62)
1 "^[[>" 91 (62)
2 "^[[>" 62 nil
3 3

and for aterm

0 "^[[?" 27 nil
1 "^[[?" 91 nil
2 "^[[?" 63 nil
3 3
0 "^[[>" nil nil
0 3


So the xterm case has stuff pushed into unread-command-events by the
first handler, which is then there for the second handler to read.

aterm does not, so the second handler has nothing to read.

So I can make aterm fast, and xterm slow, by swapping the order of the 
 ("\e[?" . xterm--version-handler)
 ("\e[>" . xterm--version-handler)

Message #21 received at 14615 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 14615 <at> debbugs.gnu.org
Subject: Re: bug#14615: xterm--query results in slow -nw startup on some
 terminals
Date: Fri, 14 Jun 2013 12:20:42 -0400

Something like this? It can be made more sophisticated if in the
multiple handler case more than one handler might need to get run, but
the current code does not require that anywhere.


*** lisp/term/xterm.el	2013-05-15 23:55:41 +0000
--- lisp/term/xterm.el	2013-06-14 16:17:37 +0000
***************
*** 544,550 ****
                                   nil))))
            (setq i (1+ i)))
          (if (= i (length (car handler)))
!             (funcall (cdr handler))
            (while (> i 0)
              (push (aref (car handler) (setq i (1- i)))
                    unread-command-events)))))))
--- 544,551 ----
                                   nil))))
            (setq i (1+ i)))
          (if (= i (length (car handler)))
!             (progn (setq handlers nil)
!                    (funcall (cdr handler)))
            (while (> i 0)
              (push (aref (car handler) (setq i (1- i)))
                    unread-command-events)))))))

Message #24 received at 14615 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 14615 <at> debbugs.gnu.org
Subject: Re: bug#14615: xterm--query results in slow -nw startup on some
 terminals
Date: Fri, 14 Jun 2013 14:08:13 -0400

> !             (funcall (cdr handler))
[...]
> !             (progn (setq handlers nil)
> !                    (funcall (cdr handler)))

Oops, yes, thanks for catching this.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.