unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#14615: xterm--query results in slow -nw startup on some terminals
@ 2013-06-13 23:36 Glenn Morris
  2013-06-14  0:26 ` Stefan Monnier
  0 siblings, 1 reply; 8+ messages in thread
From: Glenn Morris @ 2013-06-13 23:36 UTC (permalink / raw)
  To: 14615

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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#14615: xterm--query results in slow -nw startup on some terminals
  2013-06-13 23:36 bug#14615: xterm--query results in slow -nw startup on some terminals Glenn Morris
@ 2013-06-14  0:26 ` Stefan Monnier
  2013-06-14  0:34   ` Glenn Morris
  0 siblings, 1 reply; 8+ messages in thread
From: Stefan Monnier @ 2013-06-14  0:26 UTC (permalink / raw)
  To: Glenn Morris; +Cc: 14615

> 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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#14615: xterm--query results in slow -nw startup on some terminals
  2013-06-14  0:26 ` Stefan Monnier
@ 2013-06-14  0:34   ` Glenn Morris
  2013-06-14  1:17     ` Stefan Monnier
  0 siblings, 1 reply; 8+ messages in thread
From: Glenn Morris @ 2013-06-14  0:34 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 14615

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.





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#14615: xterm--query results in slow -nw startup on some terminals
  2013-06-14  0:34   ` Glenn Morris
@ 2013-06-14  1:17     ` Stefan Monnier
  2013-06-14  1:36       ` Glenn Morris
  0 siblings, 1 reply; 8+ messages in thread
From: Stefan Monnier @ 2013-06-14  1:17 UTC (permalink / raw)
  To: Glenn Morris; +Cc: 14615

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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#14615: xterm--query results in slow -nw startup on some terminals
  2013-06-14  1:17     ` Stefan Monnier
@ 2013-06-14  1:36       ` Glenn Morris
  2013-06-14  7:38         ` Glenn Morris
  0 siblings, 1 reply; 8+ messages in thread
From: Glenn Morris @ 2013-06-14  1:36 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 14615

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.





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#14615: xterm--query results in slow -nw startup on some terminals
  2013-06-14  1:36       ` Glenn Morris
@ 2013-06-14  7:38         ` Glenn Morris
  2013-06-14 16:20           ` Glenn Morris
  0 siblings, 1 reply; 8+ messages in thread
From: Glenn Morris @ 2013-06-14  7:38 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 14615


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)





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#14615: xterm--query results in slow -nw startup on some terminals
  2013-06-14  7:38         ` Glenn Morris
@ 2013-06-14 16:20           ` Glenn Morris
  2013-06-14 18:08             ` Stefan Monnier
  0 siblings, 1 reply; 8+ messages in thread
From: Glenn Morris @ 2013-06-14 16:20 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 14615


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






^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#14615: xterm--query results in slow -nw startup on some terminals
  2013-06-14 16:20           ` Glenn Morris
@ 2013-06-14 18:08             ` Stefan Monnier
  0 siblings, 0 replies; 8+ messages in thread
From: Stefan Monnier @ 2013-06-14 18:08 UTC (permalink / raw)
  To: Glenn Morris; +Cc: 14615

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

Oops, yes, thanks for catching this.


        Stefan





^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2013-06-14 18:08 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-06-13 23:36 bug#14615: xterm--query results in slow -nw startup on some terminals Glenn Morris
2013-06-14  0:26 ` Stefan Monnier
2013-06-14  0:34   ` Glenn Morris
2013-06-14  1:17     ` Stefan Monnier
2013-06-14  1:36       ` Glenn Morris
2013-06-14  7:38         ` Glenn Morris
2013-06-14 16:20           ` Glenn Morris
2013-06-14 18:08             ` Stefan Monnier

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).