bug#14615: xterm--query results in slow -nw startup on some terminals

bug#14615: xterm--query results in slow -nw startup on some terminals

[Glenn Morris]

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

bug#14615: xterm--query results in slow -nw startup on some terminals

[Stefan Monnier]

> 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

bug#14615: xterm--query results in slow -nw startup on some terminals

[Glenn Morris]

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.

bug#14615: xterm--query results in slow -nw startup on some terminals

[Stefan Monnier]

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

bug#14615: xterm--query results in slow -nw startup on some terminals

[Glenn Morris]

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.

bug#14615: xterm--query results in slow -nw startup on some terminals

[Glenn Morris]

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)

bug#14615: xterm--query results in slow -nw startup on some terminals

[Glenn Morris]

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

bug#14615: xterm--query results in slow -nw startup on some terminals

[Stefan Monnier]

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

Oops, yes, thanks for catching this.


        Stefan