Re: terminal emulator compatible with Ecma-48
Le Dim 28 avril 2013 17:59, Roger Leigh a écrit :
> The standard is not intended to be
> implemented in its entirety from my reading of it
We have the same document :)
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 :)
Reply to: