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