bug-gnu-emacs
[Top][All Lists]
Advanced

[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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]