[Bug 1297051] Re: gnome-terminal doesn't recognise C1 controls

[Egmont Koblinger]

> In an ideal world we would not have to do this because...

I disagree.  Such an approach would prevent innovation, at least, there
wouldn't be a way to communicate new features towards applications.  In
an ideal world, you could dynamically query the terminal for features
and it would respond in a well-defined (standard but extendable) format.
Or at least they'd identify themselves with a hardcoded name and version
number (again, using a well-defined format), similarly to browsers'
user-agent.

> quirks and limitations of individual emulations e.g. knowing that I
have to send ESC[?40h for a width change.

This doesn't sounds like a quirk to me.  The fact that xterm does so
makes me believe that whichever physical terminal implemented this
feature probably implemented it this way and hence this is the standard
way to do it.  If you omitted \e[?40h it's a bug in your app that you
should fix and emit this escape unconditionally for all terminals.  I
might be wrong though.

Not having a standard response for ENQ, not even a container syntax
(e.g. a fixed leading escape sequence and trailing character) makes it
pretty braindamaged straight away.  It only works if you make up your
own arbitrary in-house rules (e.g. terminate by newline), configure all
your terminals and change all your apps, something that probably nobody
in the world is willing to do except for you.  There's no way for an app
to know if the response was indeed sent as a response, or (maybe just
some of its characters) typed in by the user.  Having to configure the
terminals is already a wrong approach anyways, it's a thing that should
work out of the box without configuring.  Having to change all the
applications running inside terminals to behave accordingly, maintaining
them consistently (and duplicating relevant code in all of them - or are
you maintaining your own screen drawing library?) sounds like a
nightmare.

There are similar already existing methods for getting the actual
terminal version and capabilities - note that all of them suck, but at
least they are used widely.  There's the TERM variable and the
corresponding underlying termcap/terminfo database and common screen
libraries (ncurses, slang) using these; there's the \e[c and \e[>c
escapes that are recognized more commonly and have a well-defined
response syntax+semantics, there's $VTE_VERSION (well, until you log in
to a remote host).  Plus, you can always just safely use the common
subset of escape characters that are understood by all terminals.

Many modern terminal emulators (e.g. konsole, terminology, st) don't
support setting an ENQ response either.  If you rely on this feature, it
sounds to me that you're using a really odd nonstandard way to solve a
problem.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to vte3 in Ubuntu.
https://bugs.launchpad.net/bugs/1297051

Title:
  gnome-terminal doesn't recognise C1 controls

Status in “vte3” package in Ubuntu:
  New

Bug description:
  gnome-terminal seems not to recognise the C1 control characters.

  The particular character that is a problem for me is CSI. However
  there may be a generic issue with non-support of this whole range of
  characters.

  This range of characters should only be recognised when the encoding
  is a character set that is defined to include the C1 control
  characters but, at a quick look, that is all of the ISO-8859-x
  character sets and Unicode. (C1 control characters require encoding as
  a 2 byte sequence when the encoding is UTF-8. As unlikely as this may
  be to occur in practice, UTF-8 is not inconsistent with C1 control
  characters.)

  Part of the motivation for raising this bug report is that PuTTY seems
  to have declined in reliability recently and so I looked at why I am
  using PuTTY as opposed to gnome-terminal. Correct support of C1
  control characters is one reason. This works in PuTTY. It does not
  appear to work in gnome-terminal. Perhaps resources would be better
  spent making gnome-terminal work as well as PuTTY does, rather than
  attempting to get PuTTY fixed.

  ProblemType: Bug
  DistroRelease: Ubuntu 13.10
  Package: gnome-terminal 3.6.1-0ubuntu6
  ProcVersionSignature: Ubuntu 3.11.0-18.32-generic 3.11.10.4
  Uname: Linux 3.11.0-18-generic x86_64
  NonfreeKernelModules: nvidia
  ApportVersion: 2.12.5-0ubuntu2.2
  Architecture: amd64
  Date: Tue Mar 25 11:08:00 2014
  InstallationDate: Installed on 2011-10-25 (881 days ago)
  InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
  MarkForUpload: True
  SourcePackage: gnome-terminal
  UpgradeStatus: Upgraded to saucy on 2013-11-08 (136 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vte3/+bug/1297051/+subscriptions