[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#16988: xterm--version-handler, accepting any terminal type rather th
From: |
W. Trevor King |
Subject: |
bug#16988: xterm--version-handler, accepting any terminal type rather than 0 |
Date: |
Wed, 12 Mar 2014 09:13:24 -0700 |
User-agent: |
Mutt/1.5.22 (2013-10-16) |
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
Description: OpenPGP digital signature