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)
I did read ECMA-48 5th ed. very carefully before designing this syntax.
http://www.cl.cam.ac.uk/~mgk25/ucs/scw-proposal.html
http://www.ecma.ch/ecma1/STAND/ECMA-048.HTM
If I dropped the ":" and ";" mechanism (which isn't essential for width
control anyway and was just more a curious idea for a somewhat related
potentially useful add-on for debugging purposes) or found an
alternative syntax (like "=:" and ">:") for it if people want it really,
then the parameter string would remain completely within the format
explicitly reserved for private and experimental extensions, because it
will always start with a character in the 03/12-03/15 (<=>?) range.
> The Parameter Bytes are bit combinations from 03/00 to 03/15. The
> parameter string is interpreted as follows:
> a) If the first bit combination of the parameter string is in the range
> 03/00 to 03/11, the parameter string is interpreted according to the
> format described in 5.4.2.
Read the spec completely. You dropped the relevant immediately following
option:
b) If the first bit combination of the parameter string is in the range
03/12 to 03/15, the parameter string is available for private (or
experimental) use. Its format and meaning are not defined by this
Standard.
> The general idea is that if it starts with a digit, ':' or ';' it must
> follow the normal list of numbers rules.
It doesn't and thus signals the emulator to by-pass the normal parser
here. Should really be trivial to implement (< 150 added lines of code)
and not break any conforming existing emulators.
> 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
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.
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
characters. DCS strings on the other hand are allowed to contain LF,
etc.
Markus
--
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
