On Sun, 27 May 2001, Markus Kuhn wrote:
> Robert de Bath wrote on 2001-05-27 09:27 UTC:
> > OMG. That would be evil to implement within an existing ANSI 'collector'.
> > It is also illegal according to ECMA-48 (5th ed)
> If I dropped the ":" and ";" mechanism (which isn't essential for width
Okay at that point you are within ECMA-48, but only because it says there
aren't any rules!
BUT the _only_ code I've ever seen that doesn't follow 5.4.2 for all
those sequences was an ansi stripper that didn't actually decode the ansi.
AND _every_ other defined ANSI sequence public or private follows the
5.4.2 rules and contains a maximum of one character from 02/00..02/15
and 03/00..03/15 (very few sequences have characters from both)
> Read the spec completely. You dropped the relevant immediately following
> option:
I did and did, because you didn't say the ':' ';' part was optional in
your proposal - I only skimmed the message (sorry).
BTW: 99 is far too low 170 cols is easy and over 200 can be readable.
> It doesn't and thus signals the emulator to by-pass the normal parser
Definitly not. The VT100 emulation contains CSI ? 26 n, CSI > c and
several other sets, the SCO ANSI emulation contins a load of CSI = ...
sequences. They all follow 5.4.2.
> here. Should really be trivial to implement (< 150 added lines of code)
> and not break any conforming existing emulators.
You'd probably end up running both the old integer collector and another
one just for your sequence in parallel; irritating.
> > The normal way to implement a special string is with a DCS code eg..
> >
> > ESC P w (*$&%(*^$(%<>?:@~@!"~# ST
>
> I doubt, existing terminal emulators (counting only those with less
> brain damaged control function parsers than the sad Linux console) would
> ignore such a sequence properly if unknown, whereas they would ignore
> mine as it is within the normal syntax. You could bracket the string
They _might_ ignore it, as you probably tested neither the Linux console
nor current (I tried XF86 3.3.6) xterm versions ignore it. The only ones
that I found quickly were a real WY120 terminal and PuTTY.
(PS: Jeffrey, I didn't try kermit ...)
> with the C1 control character DCS and ST, but that's clumsy and
> overloads DCS with a meaning that has to be identified via a separate
> sequence, whereas we want to avoid long-term state.
Yes there would be long term state; it's called the terminal type.
The sequence I gave follows the VT220 implementation of DCS strings
where the first part of the string is a set of CSI style P I and F
bytes followed by an ST terminated string.
Many terminal emulators implement no DCS sequences and so don't
understand DCS at all but this appears to be no different to the
effect of your breaking of the conventions of CSI strings.
> Using the plain normal command syntax where the parameter string is
> restricted to the third ASCII column (0-?) seems much safer to me,
> because any other character will terminate or abort the control
> sequence, which sounds less accident prone than having to wait on one
> particular C1 STRING TERMINATOR byte (what if that got corrupted?).
> My SCW proposal gets aborted by the next LF, which makes it rather safe
> as the effect is restricted to a single line (except for the ":" and ";"
> bits, which I said is more for discussion and I don't mind if you prefer
> not to implement it). The aborting property of LF holds for both the
> sequence itself as well as for the sequence of affected graphic
NO NO! This is a VERY common mistake! Embedded control characters do
NOT abort CSI sequences. ECMA-48 highlights the SO and SI characters
but a VT emulation must allow everything except ESC and CAN which have
specifically defined effects.
This _cannot_ be changed for your sequence because we don't know it's
yours till we get to the end of it.
> characters. DCS strings on the other hand are allowed to contain LF,
> etc.
There's also a very good chance that the terminal already has either
DCS sequences (ReGIS/Sixel graphics, VT220 reports, VT400 macros) or
other ST terminated sequences (sysline, window/icon title) so another
one isn't going to make a difference.
--
Rob. (Robert de Bath <rdebath @ poboxes.com>)
<http://www.cix.co.uk/~mayday>
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
