GNU bug report logs -
#16988
24.3.50; emacs -nw -Q --eval '(kill-emacs)' takes 2 seconds unless I hit a key
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 16988 in the body.
You can then email your comments to 16988 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16988
; Package
emacs
.
(Tue, 11 Mar 2014 15:24:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 11 Mar 2014 15:24:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16988
; Package
emacs
.
(Tue, 11 Mar 2014 17:19:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 16988 <at> debbugs.gnu.org (full text, mbox):
> From: Nicolas Richard <theonewiththeevillook <at> 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 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16988
; Package
emacs
.
(Tue, 11 Mar 2014 19:09:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 16988 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16988
; Package
emacs
.
(Wed, 12 Mar 2014 10:37:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 16988 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16988
; Package
emacs
.
(Wed, 12 Mar 2014 14:33:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 16988 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
[Message part 2 (message/rfc822, inline)]
Eli Zaretskii <eliz <at> 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 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16988
; Package
emacs
.
(Wed, 12 Mar 2014 16:14:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 16988 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16988
; Package
emacs
.
(Wed, 26 Mar 2014 02:45:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 16988 <at> debbugs.gnu.org (full text, mbox):
> 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...)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16988
; Package
emacs
.
(Wed, 26 Mar 2014 06:48:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 16988 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16988
; Package
emacs
.
(Wed, 26 Mar 2014 10:30:04 GMT)
Full text and
rfc822 format available.
Message #29 received at 16988 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16988
; Package
emacs
.
(Wed, 26 Mar 2014 12:47:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 16988 <at> debbugs.gnu.org (full text, mbox):
> + ;; 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16988
; Package
emacs
.
(Wed, 26 Mar 2014 13:39:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 16988 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> 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.
Reply sent
to
Stefan Monnier <monnier <at> IRO.UMontreal.CA>
:
You have taken responsibility.
(Tue, 22 Apr 2014 20:37:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
:
bug acknowledged by developer.
(Tue, 22 Apr 2014 20:37:03 GMT)
Full text and
rfc822 format available.
Message #40 received at 16988-done <at> debbugs.gnu.org (full text, mbox):
> 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
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 21 May 2014 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 9 years and 314 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.