* bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key
@ 2014-03-11 15:22 Nicolas Richard
2014-03-11 17:18 ` Eli Zaretskii
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Nicolas Richard @ 2014-03-11 15:22 UTC (permalink / raw)
To: 16988
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key
2014-03-11 15:22 bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key Nicolas Richard
@ 2014-03-11 17:18 ` Eli Zaretskii
2014-03-11 19:08 ` Nicolas Richard
2014-03-12 8:59 ` Nicolas Richard
2014-03-12 14:32 ` bug#16988: xterm--version-handler, accepting any terminal type rather than 0 Stefan Monnier
2014-03-26 2:44 ` bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key Stefan Monnier
2 siblings, 2 replies; 12+ messages in thread
From: Eli Zaretskii @ 2014-03-11 17:18 UTC (permalink / raw)
To: Nicolas Richard; +Cc: 16988
> 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key
2014-03-11 17:18 ` Eli Zaretskii
@ 2014-03-11 19:08 ` Nicolas Richard
2014-03-12 8:59 ` Nicolas Richard
1 sibling, 0 replies; 12+ messages in thread
From: Nicolas Richard @ 2014-03-11 19:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Nicolas Richard, 16988
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key
2014-03-11 17:18 ` Eli Zaretskii
2014-03-11 19:08 ` Nicolas Richard
@ 2014-03-12 8:59 ` Nicolas Richard
1 sibling, 0 replies; 12+ messages in thread
From: Nicolas Richard @ 2014-03-12 8:59 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Nicolas Richard, 16988
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#16988: xterm--version-handler, accepting any terminal type rather than 0
2014-03-11 15:22 bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key Nicolas Richard
2014-03-11 17:18 ` Eli Zaretskii
@ 2014-03-12 14:32 ` Stefan Monnier
2014-03-12 16:13 ` W. Trevor King
2014-03-26 2:44 ` bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key Stefan Monnier
2 siblings, 1 reply; 12+ messages in thread
From: Stefan Monnier @ 2014-03-12 14:32 UTC (permalink / raw)
To: W. Trevor King; +Cc: 16988, Nicolas Richard
[-- 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#16988: xterm--version-handler, accepting any terminal type rather than 0
2014-03-12 14:32 ` bug#16988: xterm--version-handler, accepting any terminal type rather than 0 Stefan Monnier
@ 2014-03-12 16:13 ` W. Trevor King
0 siblings, 0 replies; 12+ messages in thread
From: W. Trevor King @ 2014-03-12 16:13 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 16988, Nicolas Richard
[-- 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 --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key
2014-03-11 15:22 bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key Nicolas Richard
2014-03-11 17:18 ` Eli Zaretskii
2014-03-12 14:32 ` bug#16988: xterm--version-handler, accepting any terminal type rather than 0 Stefan Monnier
@ 2014-03-26 2:44 ` Stefan Monnier
2014-03-26 6:47 ` Nicolas Richard
2014-03-26 10:29 ` Nicolas Richard
2 siblings, 2 replies; 12+ messages in thread
From: Stefan Monnier @ 2014-03-26 2:44 UTC (permalink / raw)
To: Nicolas Richard; +Cc: 16988
> 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...)
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key
2014-03-26 2:44 ` bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key Stefan Monnier
@ 2014-03-26 6:47 ` Nicolas Richard
2014-03-26 10:29 ` Nicolas Richard
1 sibling, 0 replies; 12+ messages in thread
From: Nicolas Richard @ 2014-03-26 6:47 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Nicolas Richard, 16988
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key
2014-03-26 2:44 ` bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key Stefan Monnier
2014-03-26 6:47 ` Nicolas Richard
@ 2014-03-26 10:29 ` Nicolas Richard
2014-03-26 12:46 ` Stefan Monnier
1 sibling, 1 reply; 12+ messages in thread
From: Nicolas Richard @ 2014-03-26 10:29 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 16988
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.
^ permalink raw reply related [flat|nested] 12+ messages in thread
* bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key
2014-03-26 10:29 ` Nicolas Richard
@ 2014-03-26 12:46 ` Stefan Monnier
2014-03-26 13:38 ` Nicolas Richard
0 siblings, 1 reply; 12+ messages in thread
From: Stefan Monnier @ 2014-03-26 12:46 UTC (permalink / raw)
To: Nicolas Richard; +Cc: 16988
> + ;; 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key
2014-03-26 12:46 ` Stefan Monnier
@ 2014-03-26 13:38 ` Nicolas Richard
2014-04-22 20:36 ` Stefan Monnier
0 siblings, 1 reply; 12+ messages in thread
From: Nicolas Richard @ 2014-03-26 13:38 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Nicolas Richard, 16988
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key
2014-03-26 13:38 ` Nicolas Richard
@ 2014-04-22 20:36 ` Stefan Monnier
0 siblings, 0 replies; 12+ messages in thread
From: Stefan Monnier @ 2014-04-22 20:36 UTC (permalink / raw)
To: Nicolas Richard; +Cc: 16988-done
> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2014-04-22 20:36 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-03-11 15:22 bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key Nicolas Richard
2014-03-11 17:18 ` Eli Zaretskii
2014-03-11 19:08 ` Nicolas Richard
2014-03-12 8:59 ` Nicolas Richard
2014-03-12 14:32 ` bug#16988: xterm--version-handler, accepting any terminal type rather than 0 Stefan Monnier
2014-03-12 16:13 ` W. Trevor King
2014-03-26 2:44 ` bug#16988: 24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key Stefan Monnier
2014-03-26 6:47 ` Nicolas Richard
2014-03-26 10:29 ` Nicolas Richard
2014-03-26 12:46 ` Stefan Monnier
2014-03-26 13:38 ` Nicolas Richard
2014-04-22 20:36 ` Stefan Monnier
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.