I have upgraded one Linux computer to Wily Werewolf, so I took the
opportunity of retesting this.
I can confirm that this now works. So this bug can be closed.
As suggested above, it is unlikely that any system that expects to be
talking to real terminals will use UTF-8. Hence it is most likely
It is possible to set the encoding, temporarily (for the given tab only)
under Terminal, or permanently as the new default for a profile under
Profile Preferences -> Compatibility.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I've added C1 support to git master. It'll hopefully make it into Ubuntu
15.10 W W.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1297051
Title:
gnome-terminal doesn't recognise C1 controls
To
Coming first to \e[?40h ...
I'm really not an expert on the terminal emulation topic (especially in
these rarely used areas that you're interested in), don't feel
comfortable changing anything. (In my personal opinion, no matter how
physical terminals worked a couple of decades ago, on a modern
Applications running inside the terminal should not be able to
resize/move/iconize/raise the window.
That is a completely valid choice. However \e[?40h fails to implement
that. All it does is force the host to send one extra escape sequence
(if it knows that it needs to send it). As such
I was actually wondering about the same... App-controled resized kinda
only makes sense with another setting that would inhibit a window
manager initiated resize.
Gnome-terminal is actually vte (the real terminal emulation) + gnome-
terminal (only the UI menus, tabs and such). If you don't care
Regarding DA3, as you point out, the spec is woefully inadequate for
today's world. It also doesn't seem to work for the real terminal that
I tested. It is also not currently implemented at all by xterm. That is
why I have no qualms about proposing to extend the DA3 response sequence
for other
The response to \e[c should contain the version number. Well, in case
of xterm it contains that. Now, some emulators (e.g. vte) put their own
version number there, while some others (e.g. konsole) put the version
of xterm it claims to be compatible with.
Imagine there'd be a brand new escape
I don't disagree that sending the software product name and version
invites some problems. However coming back to what I wrote initially -
Knowing the actual make and model allows us to account for quirks and
limitations of individual emulations - is the crux of it. I don't
actually care about
Coming first to \e[?40h ...
a) I grepped the VT2xx manual.
b) I browsed the VT5xx manual.
c) I tested it on a real VT5xx terminal.
d) I happened to find it documented in man 5 dtterm on a particular
flavour of Unix. (dtterm was/is an X-windows terminal emulator.)
I am highly confident that
Here's an alternative suggestion for identifying the terminal
implementation: Implement the DA3 sequence and implement the extension
proposed below.
DA3 is supposed to elicit a globally unique, persistent terminal
identifier (its serial number if you like), as documented here:
http://www.vt100.net/ is a good source of information because it uses
the original manuals for the real terminals.
http://www.vt100.net/docs/vt510-rm/DA1 defines how \e[c works but it
isn't adequate to express the capability of a terminal. In particular it
doesn't cater for emulations that are
It's true that we could have defined the answerback response to have a
syntax that basically matches the response to \e[c ...
That's a crucial issue here. If all terminals responded in a well-
defined syntax (i.e. some_unique_prefixterminalnameterminator) then
I'd happily move ahead and
Looking at the source, it is necessary to send ESC[?40h
This is the intended behavior, matching xterm and http://invisible-
island.net/xterm/ctlseqs/ctlseqs.html
Answerback does not work
Yup. What would be a practical use for this feature? Note that VTE is
not developed along the lines of
We use answerback extensively in order to identify the make and model of
terminal i.e. every terminal that we have, physical or emulated, is
configured to respond to ENQ with its make and model (followed by a
carriage return).
In an ideal world we would not have to do this because every terminal
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
On 05/08/14 10:17, Egmont Koblinger wrote:
./src/vte-2.91 --encoding=latin1 # or whichever other encoding you
wish to use
An additional comment on this ... if I use latin1 encoding then normal
shell commands like 'man' have glitches in their output, presumably
because they use Unicode
Could you please try the 2nd patch? It should fix RI, OSC and friends.
What's the terminator character used by VMS when emitting an OSC
sequence? The terminator can be either a BEL ('\a', ASCII 7) or an ST,
whereas the ST has two version: the 7-bit clean ESC \, and the C1
counterpart 0x9C.
in the program that I built from source as per your instructions, this
feature seems to have disappeared.
This program is a test application for testing the actual terminal
emulation only. If you wish to see gnome-terminal getting this feature
(beware, it's a bit hairy, don't break your system,
I've tested the second patch.
RI now works.
I tried OSC ... ST in both the unmixed C1 form and the unmixed ESC form.
They both work.
Hunting around the internet, the unmixed ESC form seems more common. I
am not worried that they wouldn't work in a mixed form. That would be
fairly perverse. I am
I've added a patch to the upstream bugreport.
boon, could you please test that?
Could you please also let us know what application(s) produce these
kinds of escape sequences?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
On 05/08/14 05:31, Egmont Koblinger wrote:
I've added a patch to the upstream bugreport.
boon, could you please test that?
Please excuse my ignorance but I don't know how to do that. Can you tell
me what commands to type?
Is it in a repository somewhere or do I have to build from source?
Please excuse my ignorance but I don't know how to do that. Can you tell
me what commands to type?
Is it in a repository somewhere or do I have to build from source?
You need to build from source, which goes something like this:
wget
On 05/08/14 10:17, Egmont Koblinger wrote:
which goes something like this:
OK, after a certain amount of guessing and over 1GB of download and
install, yes, I managed to do that.
It does appear that it is now correctly recognising the CSI character.
However that then reveals another problem.
Could you provide concrete escape sequences (like an echo command, or a
short text file to cat)?
I can't figure out how to test this. CSI is traditionally ESC + [. This is used
e.g. to change the foreground color:
echo -e '\x1B[31mred\x1B[0m'
The CSI you're referring to seems to be an alternate
I figured out it works in xterm and putty with ISO-8859-x charsets, just
not with UTF-8.
Reported the request upstream:
https://bugzilla.gnome.org/show_bug.cgi?id=730154
** Bug watch added: GNOME Bug Tracker #730154
https://bugzilla.gnome.org/show_bug.cgi?id=730154
--
You received this bug
26 matches
Mail list logo
