Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
terminal emulator compatible with Ecma-48
53 views
Skip to first unread message
berenge...@neutralite.org
Apr 26, 2013, 8:40:01 PM4/26/13
to
Hello.
I know that most terminal emulators support most VT100 escape
sequences, which are based on ecma-48, but as far as I know, they are
not able to support the full standard. By example, they only support 7
bit sequences, and so CSI is 0x1B5B only, were ecma-48 says it can be
0x9B too. It also seems that blinking is not supported.
So, I would like to know if someone knows about a terminal emulator
supporting all the standard or, at least, which explicitly says which
part of it it supports.
Thanks you.
Note:
I'm simply playing with it to write a text editor inspired by mpd/mpc
which includes feature I have only seen partially implemented in editors
based on scintilla like multi-line editing (which stops when you try to
move cursor or to insert multiple lines, by example). I do not think it
will reach a good enough point to help someone else than me
(auto-completion will be an interesting challenge too :) ), and am
mostly doing it for fun.
The use of Ecma-48 is only here to avoid creation of a protocol when I
can use an easy to extend standard, and console clients are far easier
and faster to implement than graphical ones.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/532d1c3ff3b024f5...@neutralite.org
I know that most terminal emulators support most VT100 escape
sequences, which are based on ecma-48, but as far as I know, they are
not able to support the full standard. By example, they only support 7
bit sequences, and so CSI is 0x1B5B only, were ecma-48 says it can be
0x9B too. It also seems that blinking is not supported.
So, I would like to know if someone knows about a terminal emulator
supporting all the standard or, at least, which explicitly says which
part of it it supports.
Thanks you.
Note:
I'm simply playing with it to write a text editor inspired by mpd/mpc
which includes feature I have only seen partially implemented in editors
based on scintilla like multi-line editing (which stops when you try to
move cursor or to insert multiple lines, by example). I do not think it
will reach a good enough point to help someone else than me
(auto-completion will be an interesting challenge too :) ), and am
mostly doing it for fun.
The use of Ecma-48 is only here to avoid creation of a protocol when I
can use an easy to extend standard, and console clients are far easier
and faster to implement than graphical ones.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/532d1c3ff3b024f5...@neutralite.org
Chris Davies
Apr 28, 2013, 11:30:01 AM4/28/13
to
berenge...@neutralite.org wrote:
> I know that most terminal emulators support most VT100 escape
> sequences, which are based on ecma-48
I'd extend that to suggest that most terminal emulators support the
> I know that most terminal emulators support most VT100 escape
> sequences, which are based on ecma-48
majority of VT220 sequences, not just the VT100 subset.
> but as far as I know, they are
> not able to support the full standard. By example, they only support 7
> bit sequences, and so CSI is 0x1B5B only, were ecma-48 says it can be
> 0x9B too.
that lxterm does not support \x9b as an alternative to \x1b\5b.
> It also seems that blinking is not supported.
just not by default.
tput blink; echo hello; tput sgr0
hello <- this flashes in lxterm
> So, I would like to know if someone knows about a terminal emulator
> supporting all the standard or, at least, which explicitly says which
> part of it it supports.
or else documented what it hasn't implemented. This might be a good
starting point.
Chris
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Roger Leigh
Apr 28, 2013, 12:00:03 PM4/28/13
to
On Sat, Apr 27, 2013 at 02:36:47AM +0200, berenge...@neutralite.org wrote:
> I know that most terminal emulators support most VT100 escape
> sequences, which are based on ecma-48, but as far as I know, they
> are not able to support the full standard. By example, they only
> support 7 bit sequences, and so CSI is 0x1B5B only, were ecma-48
> says it can be 0x9B too. It also seems that blinking is not
> supported.
ECMA-48 is a huge standard, and the VT series terminals only implement
> I know that most terminal emulators support most VT100 escape
> sequences, which are based on ecma-48, but as far as I know, they
> are not able to support the full standard. By example, they only
> support 7 bit sequences, and so CSI is 0x1B5B only, were ecma-48
> says it can be 0x9B too. It also seems that blinking is not
> supported.
a tiny fraction of its capabilities. The standard is not intended to
be implemented in its entirety from my reading of it; hardware
implementations should implement the subset of it which is appropriate
for a particular application. That said, such a terminal would be
quite desirable to have. Though time has moved on, and there are a
number of shortcomings in the standard which any implementor would
want to address, probably via vendor-specific extensions.
One thing which has puzzled me for some time is why xterm, and all
the other terminal emulators, including the Linux console, chose
the VT100 to emulate. It's a long-obsolete and poorly-featured
terminal. There are much more fully-featured terminals which came
after it, and given that all terminals are now implemented in
software, it would be perfectly possible to implement very advanced
functionality such as SVG-compatible vector graphics and OpenGL in
terms of the escape command sequences (or an equivalent alternative).
> So, I would like to know if someone knows about a terminal emulator
> supporting all the standard or, at least, which explicitly says
> which part of it it supports.
that even the "VT100-compatible" emulators all support only a
subset of the full VT100 command set.
I've had plans to write a "new" terminal emulator for several years;
lack of time due to doing a PhD has prevented this, but I'm planning
on picking it up again at some point. I have a print copy of all
the ECMA/ISO terminal-related specs, and I implemented all the
CL/CR/GL/GR mapping stuff you're referring to in my "uterm"
terminal emulator project; this was implemented in GTK+ back in 2005,
and it even included a gnome-canvas-based code table editor, but I
deleted the project on Alioth a year or so back, and the Arch repo.
I plan to resurrect it after porting the GObject-based stuff to C++.
But I've got a number of higher-priority projects waiting before I get
to this.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
John Hasler
Apr 28, 2013, 12:50:01 PM4/28/13
to
Roger Leigh writes:
> One thing which has puzzled me for some time is why xterm, and all the
> other terminal emulators, including the Linux console, chose the VT100
> to emulate.
To support commercial software that had VT100 escape sequences hard coded.
> One thing which has puzzled me for some time is why xterm, and all the
> other terminal emulators, including the Linux console, chose the VT100
> to emulate.
--
John Hasler
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
"Morel Bérenger"
Apr 29, 2013, 4:50:01 AM4/29/13
to
Le Dim 28 avril 2013 17:59, Roger Leigh a �crit :
But it says that to be compliant (it says exactly that it would be a
"limited conformance"), one must say which parts of it are implemented, or
are not. (see 2.1)
> That said, such a terminal would be quite
> desirable to have. Though time has moved on, and there are a number of
> shortcomings in the standard which any implementor would want to address,
> probably via vendor-specific extensions.
Vendor-specific extensions have an official place in the current standard.
But as you said, the standard is huge, so just having a full
implementation, or one without deprecated stuff (as modes) would be a
probably more than what I will need :D
But it could really be useful.
> terminals are now implemented in software, it would be perfectly possible
> to implement very advanced functionality such as SVG-compatible vector
> graphics and OpenGL in terms of the escape command sequences (or an
> equivalent alternative).
Sounds interesting but I still see terminals as interfaces for text only,
so I must admit I have some doubts about the usefulness of supporting SVG
rendering.
Also, the standard sounds like designed to be efficient in the use of
bandwith, it uses text (numbers in fact) for parameters, but other stuff
is not really text (but often have textual representations, of course),
unlike SVG where stuff sounds really linked to character encoding (and in
my opinion, not really efficient in terms of bandwidth usage like all XML
stuff, but that's only my personal opinion).
But I do not think it is a problem, since Ecma-48 voluntarily let spaces
for further extensions. I guess the better solution here would be to use a
plug-in system: having a basic standard set hard-coded (say, VT100, to
mimic other terminals), and other sets + extensions implemented as
plug-ins (dynamic or not is not the question here) so that they would be
easier to implement and add/remove.
> I've had plans to write a "new" terminal emulator for several years;
A huge work for which I have no real clue about where to start.
And I also have some other stuff to do before even trying to think about
such a project :)
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/90464ad244b0547c33bf...@www.sud-ouest.org
> The standard is not intended to be
> implemented in its entirety from my reading of it
We have the same document :)
> implemented in its entirety from my reading of it
But it says that to be compliant (it says exactly that it would be a
"limited conformance"), one must say which parts of it are implemented, or
are not. (see 2.1)
> That said, such a terminal would be quite
> desirable to have. Though time has moved on, and there are a number of
> shortcomings in the standard which any implementor would want to address,
> probably via vendor-specific extensions.
But as you said, the standard is huge, so just having a full
implementation, or one without deprecated stuff (as modes) would be a
probably more than what I will need :D
But it could really be useful.
> terminals are now implemented in software, it would be perfectly possible
> to implement very advanced functionality such as SVG-compatible vector
> graphics and OpenGL in terms of the escape command sequences (or an
> equivalent alternative).
so I must admit I have some doubts about the usefulness of supporting SVG
rendering.
Also, the standard sounds like designed to be efficient in the use of
bandwith, it uses text (numbers in fact) for parameters, but other stuff
is not really text (but often have textual representations, of course),
unlike SVG where stuff sounds really linked to character encoding (and in
my opinion, not really efficient in terms of bandwidth usage like all XML
stuff, but that's only my personal opinion).
But I do not think it is a problem, since Ecma-48 voluntarily let spaces
for further extensions. I guess the better solution here would be to use a
plug-in system: having a basic standard set hard-coded (say, VT100, to
mimic other terminals), and other sets + extensions implemented as
plug-ins (dynamic or not is not the question here) so that they would be
easier to implement and add/remove.
> I've had plans to write a "new" terminal emulator for several years;
And I also have some other stuff to do before even trying to think about
such a project :)
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
"Morel Bérenger"
Apr 29, 2013, 4:50:02 AM4/29/13
to
Le Dim 28 avril 2013 16:45, Chris Davies a �crit :
>> So, I would like to know if someone knows about a terminal emulator
>> supporting all the standard or, at least, which explicitly says which
>> part of it it supports.
>
> The PuTTY FAQ seems to claim that it's either implemented everything
> or else documented what it hasn't implemented. This might be a good
> starting point.
>
> Chris
This sounds perfect.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/14bab6dfe32c2b79aa4b...@www.sud-ouest.org
> lxterm supports blink. PuTTY (on [at least] Windows) also supports blink
> -
> just not by default.
>
> tput blink; echo hello; tput sgr0 hello <- this flashes in lxterm
>
Thanks, I will try this one.
> -
> just not by default.
>
> tput blink; echo hello; tput sgr0 hello <- this flashes in lxterm
>
>> So, I would like to know if someone knows about a terminal emulator
>> supporting all the standard or, at least, which explicitly says which
>> part of it it supports.
>
> The PuTTY FAQ seems to claim that it's either implemented everything
> or else documented what it hasn't implemented. This might be a good
> starting point.
>
> Chris
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thomas Dickey
Apr 29, 2013, 7:20:03 AM4/29/13
to
On Sunday, April 28, 2013 11:30:01 AM UTC-4, Chris Davies wrote:
> berenge...@neutralite.org wrote:
>
> > I know that most terminal emulators support most VT100 escape
> > sequences, which are based on ecma-48
>
>
>
> I'd extend that to suggest that most terminal emulators support the
> majority of VT220 sequences, not just the VT100 subset.
unlikely - I dealt with that a few years ago:
> berenge...@neutralite.org wrote:
>
> > I know that most terminal emulators support most VT100 escape
> > sequences, which are based on ecma-48
>
>
>
> I'd extend that to suggest that most terminal emulators support the
> majority of VT220 sequences, not just the VT100 subset.
http://invisible-island.net/xterm/xterm.faq.html#compare_versions
>
>
> > but as far as I know, they are
> > not able to support the full standard. By example, they only support 7
> > bit sequences, and so CSI is 0x1B5B only, were ecma-48 says it can be
> > 0x9B too.
>
> I don't know about this, although a quick test does appear to suggest
> that lxterm does not support \x9b as an alternative to \x1b\5b.
> The PuTTY FAQ seems to claim that it's either implemented everything
> or else documented what it hasn't implemented. This might be a good
> starting point.
it's roughly comparable to rxvt - implements about 80% of VT100, but
is not a VT100 emulator due to differences in the way it does line-wrapping
(apparently because at the outset its developers were attempting to match
the SCO console).
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Chris Davies
Apr 29, 2013, 5:30:03 PM4/29/13
to
Thomas Dickey <dic...@his.com> wrote:
> What I recall of the PuTTY FAQ (a specific pointer would help) is that
> it's roughly comparable to rxvt
http://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html
> What I recall of the PuTTY FAQ (a specific pointer would help) is that
> it's roughly comparable to rxvt
Chris
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thomas Dickey
Apr 29, 2013, 8:00:02 PM4/29/13
to
On Monday, April 29, 2013 5:30:03 PM UTC-4, Chris Davies wrote:
> Thomas Dickey <dic...@his.com> wrote:
>
> > What I recall of the PuTTY FAQ (a specific pointer would help) is that
>
> > it's roughly comparable to rxvt
>
>
>
> http://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html
that's not what I meant by "specific". You stated that
> Thomas Dickey <dic...@his.com> wrote:
>
> > What I recall of the PuTTY FAQ (a specific pointer would help) is that
>
> > it's roughly comparable to rxvt
>
>
>
> http://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html
> I'd extend that to suggest that most terminal emulators support the
> majority of VT220 sequences, not just the VT100 subset.
> The PuTTY FAQ seems to claim that it's either implemented everything
> or else documented what it hasn't implemented. This might be a good
> starting point.
As I noted, PuTTY's coverage of the escape sequences makes it
roughly comparable to rxvt.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Chris Davies
Apr 30, 2013, 8:30:02 PM4/30/13
to
Thomas Dickey <dic...@his.com> wrote:
> On Monday, April 29, 2013 5:30:03 PM UTC-4, Chris Davies wrote:
>> Thomas Dickey <dic...@his.com> wrote:
>> > What I recall of the PuTTY FAQ (a specific pointer would help) is that
> On Monday, April 29, 2013 5:30:03 PM UTC-4, Chris Davies wrote:
>> Thomas Dickey <dic...@his.com> wrote:
>> > What I recall of the PuTTY FAQ (a specific pointer would help) is that
>> http://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html
> that's not what I meant by "specific".
A misunderstanding, then.
> that's not what I meant by "specific".
> You stated that
>> I'd extend that to suggest that most terminal emulators support the
>> majority of VT220 sequences, not just the VT100 subset.
> and
>> The PuTTY FAQ seems to claim that it's either implemented everything
>> or else documented what it hasn't implemented. This might be a good
>> starting point.
> Noting where PuTTY claims/documents the "everything" would be helpful.
Chris
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages