bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key

bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key

[Nicolas Richard]

With latest trunk:
$ time src/emacs -nw -Q --eval '(kill-emacs)'

real	0m2.064s
user	0m0.030s
sys	0m0.010s

If however I hit a key, emacs exits immediately.

with 24.3 (git commit 3a1ce0685) :
$ time src/emacs -nw -Q --eval '(kill-emacs)'

real	0m0.063s
user	0m0.030s
sys	0m0.012s

The '--eval' part is just there to make emacs exit asap.

Note that replacing -Q with --batch works fine.

-- 
Nico.

bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key

[Eli Zaretskii]

> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> Date: Tue, 11 Mar 2014 16:22:21 +0100
> 
> With latest trunk:
> $ time src/emacs -nw -Q --eval '(kill-emacs)'
> 
> real	0m2.064s
> user	0m0.030s
> sys	0m0.010s

I cannot reproduce this.  I get the same 0.330s time with both current
trunk and Emacs 24.3.  That's on this system:

  eliz@fencepost:~/bzr/emacs/trunk$ uname -a
  Linux fencepost.gnu.org 2.6.32-48-server #1trisquel3 SMP Mon Jun 17 20:00:36 UTC 2013 x86_64 GNU/Linux

My crystal ball says that your TERM variable points to xterm, but your
terminal either isn't xterm or doesn't support the kind of queries
that xterm--query on xterm.el uses.  That function indeed waits for 2s
for the terminal to respond. 

bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key

[Nicolas Richard]

Eli Zaretskii <eliz@gnu.org> writes:
> I cannot reproduce this.  I get the same 0.330s time with both current
> trunk and Emacs 24.3.  That's on this system:
>
>   eliz@fencepost:~/bzr/emacs/trunk$ uname -a
>   Linux fencepost.gnu.org 2.6.32-48-server #1trisquel3 SMP Mon Jun 17 20:00:36 UTC 2013 x86_64 GNU/Linux
>
> My crystal ball says that your TERM variable points to xterm, but your
> terminal either isn't xterm or doesn't support the kind of queries
> that xterm--query on xterm.el uses.  That function indeed waits for 2s
> for the terminal to respond. 

Your crystal ball works well : I use gnome-terminal and that sets TERM
to xterm. I'll have to figure out the best way to fix that. using
TERM=gnome fixes the problem, but I don't know if that's TRT, and I
don't know either where I should set that.  I've read that:
> if [ "$COLORTERM" = "gnome-terminal" ]
> then
>     export TERM=gnome
> fi
to my .bashrc will fix it but it's not pretty.

Thanks.

--
Nico.

bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key

[Nicolas Richard]

Eli Zaretskii <eliz@gnu.org> writes:
>> $ time src/emacs -nw -Q --eval '(kill-emacs)'
>> 
>> real	0m2.064s
>> user	0m0.030s
>> sys	0m0.010s

> My crystal ball says that your TERM variable points to xterm, but your
> terminal either isn't xterm or doesn't support the kind of queries
> that xterm--query on xterm.el uses.  That function indeed waits for 2s
> for the terminal to respond. 

Since it was not a problem before, I bisected that down to commit:
commit 7e594297002c7bc07083fa8d01552255e831ba2a
Author: W. Trevor King <wking@tremily.us>
Date:   Wed Feb 19 23:45:19 2014 -0500

    * lisp/term/xterm.el (xterm--version-handler): Adapt to xterm-280's output.

which changed xterm--version-handler (in lisp/term/xterm.el) in the following way:

-    (when (string-match "0;\\([0-9]+\\);0" str)
-      (let ((version (string-to-number (match-string 1 str))))
+    ;; Since xterm-280, the terminal type (NUMBER1) is now 41 instead of 0.
+    (when (string-match "\\([0-9]+\\);\\([0-9]+\\);0" str)
+      (let ((version (string-to-number (match-string 2 str))))

That has the effect of now matching gnome-terminal's string (it begins
with 1 on my platform).

As a side effect of this, calling "emacsclient -t" from within
gnome-terminal currently acts weird : it shows the wrong buffer for up
to two second and --if you press some keys before the 2 seconds-- it
shows a few weird chars (a query to the terminal) (until next time that
part of the screen is redrawn ?).

I now see three approaches :
0. Do nothing, and let users fix their terminal emulator and/or terminfo
   entries. (alternatively : provide guidance for doing this.)
1. Like it is done now for rxvt (in function terminal-init-xterm), add
   some ad-hoc code for detecting gnome-terminal which pretends to be
   xterm (in fact the exact same approach might work : $COLORTERM is
   gnome-terminal when using gnome-terminal).
2. Test also (match-string 1 str) in the above code and make sure it is
   either 0 or 41. (it is equal to 1 in my gnome-terminal)

Opinions ?

-- 
Nico.

bug#16988: xterm--version-handler, accepting any terminal type rather than 0

[Stefan Monnier]

[-- Attachment #1: Type: text/plain, Size: 323 bytes --]

Hi Trevor,

Looks like my fear about "other terminal types" was not unfounded after
all: gnome-terminal uses a terminal type of 1 and that leads to problems
(see http://debbugs.gnu.org/16988 for the discussion).

I'm leaning towards the conservative option of replacing your "[0-9]+"
with "0\\|41", WDYT?


        Stefan


[-- Attachment #2: Type: message/rfc822, Size: 6942 bytes --]

From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Nicolas Richard <theonewiththeevillook@yahoo.fr>, 16988@debbugs.gnu.org
Subject: bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key
Date: Wed, 12 Mar 2014 09:59:13 +0100
Message-ID: <87iorj7lfv.fsf@yahoo.fr>

Eli Zaretskii <eliz@gnu.org> writes:
>> $ time src/emacs -nw -Q --eval '(kill-emacs)'
>> 
>> real	0m2.064s
>> user	0m0.030s
>> sys	0m0.010s

> My crystal ball says that your TERM variable points to xterm, but your
> terminal either isn't xterm or doesn't support the kind of queries
> that xterm--query on xterm.el uses.  That function indeed waits for 2s
> for the terminal to respond. 

Since it was not a problem before, I bisected that down to commit:
commit 7e594297002c7bc07083fa8d01552255e831ba2a
Author: W. Trevor King <wking@tremily.us>
Date:   Wed Feb 19 23:45:19 2014 -0500

    * lisp/term/xterm.el (xterm--version-handler): Adapt to xterm-280's output.

which changed xterm--version-handler (in lisp/term/xterm.el) in the following way:

-    (when (string-match "0;\\([0-9]+\\);0" str)
-      (let ((version (string-to-number (match-string 1 str))))
+    ;; Since xterm-280, the terminal type (NUMBER1) is now 41 instead of 0.
+    (when (string-match "\\([0-9]+\\);\\([0-9]+\\);0" str)
+      (let ((version (string-to-number (match-string 2 str))))

That has the effect of now matching gnome-terminal's string (it begins
with 1 on my platform).

As a side effect of this, calling "emacsclient -t" from within
gnome-terminal currently acts weird : it shows the wrong buffer for up
to two second and --if you press some keys before the 2 seconds-- it
shows a few weird chars (a query to the terminal) (until next time that
part of the screen is redrawn ?).

I now see three approaches :
0. Do nothing, and let users fix their terminal emulator and/or terminfo
   entries. (alternatively : provide guidance for doing this.)
1. Like it is done now for rxvt (in function terminal-init-xterm), add
   some ad-hoc code for detecting gnome-terminal which pretends to be
   xterm (in fact the exact same approach might work : $COLORTERM is
   gnome-terminal when using gnome-terminal).
2. Test also (match-string 1 str) in the above code and make sure it is
   either 0 or 41. (it is equal to 1 in my gnome-terminal)

Opinions ?

-- 
Nico.

bug#16988: xterm--version-handler, accepting any terminal type rather than 0

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 2528 bytes --]

On Wed, Mar 12, 2014 at 10:32:21AM -0400, Stefan Monnier wrote:
> Looks like my fear about "other terminal types" was not unfounded
> after all: gnome-terminal uses a terminal type of 1 and that leads
> to problems (see http://debbugs.gnu.org/16988 for the discussion).
> 
> I'm leaning towards the conservative option of replacing your "[0-9]+"
> with "0\\|41", WDYT?

That's going to cause problems for folks who run their XTerm in VT220
mode (xterm -ti vt220), where you'll get secondary device attributes
like '1;297;0c' (VT220, XTerm v297, ROM cartridge registration number
0).  It looks like the GNOME Terminal and it's underlying VTE widget
could use some love on the XTerm-emulation front [1,2].

On Wed, Mar 12, 2014 at 09:59:13AM +0100, Nicolas Richard wrote:
> I now see three approaches :
> 0. Do nothing, and let users fix their terminal emulator and/or
>    terminfo entries. (alternatively : provide guidance for doing
>    this.)
> 1. Like it is done now for rxvt (in function terminal-init-xterm),
>    add some ad-hoc code for detecting gnome-terminal which pretends
>    to be xterm (in fact the exact same approach might work :
>    $COLORTERM is gnome-terminal when using gnome-terminal).
> 2. Test also (match-string 1 str) in the above code and make sure it
>    is either 0 or 41. (it is equal to 1 in my gnome-terminal)

That sounds right to me, and those choices are listed in my order of
preference ;).  VTE's handling of this particular sequence
(vte_sequence_handler_send_secondary_device_attributes) hasn't changed
much since it was added in 2003 [3,4], and I haven't looked up the
sequence behind xterm--query, so I'm not sure how difficult it would
be to add support for it to VTE.  I also don't know enough about it to
know how to reliably distinguish it from true XTerms (although if you
can COLORTERM, that sounds good).  Approach #3 fixes things for VTE
users, but breaks detection for 'xterm -ti vt220' users.  I don't know
any such users personally though ;).

Cheers,
Trevor

[1]: http://invisible-island.net/xterm/xterm.faq.html#bug_gnometerm
[2]: http://invisible-island.net/xterm/xterm.faq.html#vte_widget
[3]: https://git.gnome.org/browse/vte/commit/?id=3c6d81bf06becda3f9ab005c7310b2343588115e
[4]: https://git.gnome.org/browse/vte/commit/?id=ddad9e00e4d0442d761390480aafd9c85713121f

--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key

[Stefan Monnier]

> With latest trunk:
> $ time src/emacs -nw -Q --eval '(kill-emacs)'
> real	0m2.064s
> user	0m0.030s
> sys	0m0.010s
> If however I hit a key, emacs exits immediately.

The patch below works for me, but I'm not sure if the terminal type and
version returned by gnome-terminal is "stable" or not.
Can you confirm it fixes your problem as well?


        Stefan


=== modified file 'lisp/term/xterm.el'
--- lisp/term/xterm.el	2014-03-01 18:12:16 +0000
+++ lisp/term/xterm.el	2014-03-26 02:42:05 +0000
@@ -503,6 +503,9 @@
     ;; Since xterm-280, the terminal type (NUMBER1) is now 41 instead of 0.
     (when (string-match "\\([0-9]+\\);\\([0-9]+\\);0" str)
       (let ((version (string-to-number (match-string 2 str))))
+        ;; Hack attack!  bug#16988: gnome-terminal reports "1;3409;0" but is
+        ;; based on a rather old xterm code.
+        (when (equal str "1;3409;0") (setq version 200))
         ;; If version is 242 or higher, assume the xterm supports
         ;; reporting the background color (TODO: maybe earlier
         ;; versions do too...)

bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key

[Nicolas Richard]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> With latest trunk:
>> $ time src/emacs -nw -Q --eval '(kill-emacs)'
>> real	0m2.064s
>> user	0m0.030s
>> sys	0m0.010s
>> If however I hit a key, emacs exits immediately.
>
> The patch below works for me, but I'm not sure if the terminal type and
> version returned by gnome-terminal is "stable" or not.
> Can you confirm it fixes your problem as well?

Apparently, "3409" is not stable :

For what I've tested :
Gnome terminal 3.6.1 reports 1;3406;0
Gnome terminal 2.32.1 reports 1;2802;0

-- 
Nicolas.

bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key

[Nicolas Richard]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>> With latest trunk:
>> $ time src/emacs -nw -Q --eval '(kill-emacs)'
>> real	0m2.064s
>> user	0m0.030s
>> sys	0m0.010s
>> If however I hit a key, emacs exits immediately.
>
> The patch below works for me, but I'm not sure if the terminal type and
> version returned by gnome-terminal is "stable" or not.
> Can you confirm it fixes your problem as well?

Here's a patch based on COLORTERM which works for me.

diff --git a/lisp/term/xterm.el b/lisp/term/xterm.el
index eac4014..bd5675b 100644
--- a/lisp/term/xterm.el
+++ b/lisp/term/xterm.el
@@ -503,6 +503,12 @@ The relevant features are:
     ;; Since xterm-280, the terminal type (NUMBER1) is now 41 instead of 0.
     (when (string-match "\\([0-9]+\\);\\([0-9]+\\);0" str)
       (let ((version (string-to-number (match-string 2 str))))
+        ;; gnome-terminal pretends to be xterm but lacks some of its
+        ;; more recent features.  See bug#16988.
+        (let ((colorterm (getenv "COLORTERM" (selected-frame))))
+          (when (and colorterm
+                     (string-match "\\`gnome-terminal" colorterm))
+            (setq version 200)))
         ;; If version is 242 or higher, assume the xterm supports
         ;; reporting the background color (TODO: maybe earlier
         ;; versions do too...)

--
Nico.

bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key

[Stefan Monnier]

> +        ;; gnome-terminal pretends to be xterm but lacks some of its
> +        ;; more recent features.  See bug#16988.
> +        (let ((colorterm (getenv "COLORTERM" (selected-frame))))
> +          (when (and colorterm
> +                     (string-match "\\`gnome-terminal" colorterm))
> +            (setq version 200)))

As a matter of fact, all my xterms have "COLORTERM = gnome-terminal", so
the above ends up running even though I'm in a plain uptodate xterm
rather than in a gnome-terminal.

This is probably not the usual situation (it's a result of some silly
way I log in), but it does point to the fact that xterm itself does not
reset COLORTERM, so it's not a reliable indicator.


        Stefan

bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key

[Nicolas Richard]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>> +        ;; gnome-terminal pretends to be xterm but lacks some of its
>> +        ;; more recent features.  See bug#16988.
>> +        (let ((colorterm (getenv "COLORTERM" (selected-frame))))
>> +          (when (and colorterm
>> +                     (string-match "\\`gnome-terminal" colorterm))
>> +            (setq version 200)))
>
> As a matter of fact, all my xterms have "COLORTERM = gnome-terminal", so
> the above ends up running even though I'm in a plain uptodate xterm
> rather than in a gnome-terminal.
>
> This is probably not the usual situation (it's a result of some silly
> way I log in), but it does point to the fact that xterm itself does not
> reset COLORTERM, so it's not a reliable indicator.

If we have reasons to believe xterm will never reach e.g. version 1500,
perhaps we can test for that.

-- 
Nico.

bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key

[Stefan Monnier]

> If we have reasons to believe xterm will never reach e.g. version 1500,
> perhaps we can test for that.

I installed a patch along those lines, using 2000 as the "threshold".


        Stefan