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

Previous Next

Package: emacs;

Reported by: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>

Date: Tue, 11 Mar 2014 15:24:01 UTC

Severity: important

Found in version 24.3.50

Done: Stefan Monnier <monnier <at> IRO.UMontreal.CA>

Bug is archived. No further changes may be made.

Full log


Message #20 received at 16988 <at> debbugs.gnu.org (full text, mbox):

From: "W. Trevor King" <wking <at> tremily.us>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 16988 <at> debbugs.gnu.org, Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
Subject: Re: xterm--version-handler, accepting any terminal type rather than 0
Date: Wed, 12 Mar 2014 09:13:24 -0700
[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)]

This bug report was last modified 11 years and 27 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.