> The syntax is still the same, as I am still restricted to the second
> ASCII column with my parameter string. Read ECMA-48 carefully. You start
> with CSI, then you have parameter characters (ASCII column 3) then
> intermediate bytes (ASCII column 2) and then a final byte (ASCII columns
> 4-7). So the end is very unambiguously defined, even if I don't use the
> semicolon-separated-decimal-numbers format. The end of the sequence is
> defined using a very primitive state machine based on ASCII column
> numbers, not based on the detailed syntax.
>
> Markus
>
True but in every parser I've seen:
. the ?=>< characters are parsed in combinations to set extension
flags
. the semicolon-separated-decimal-numbers are parsed to determine
the parameter list
. only then are the intermediate and final characters examined
in combination with the extension flags to determine which function
will be called.
You are arguing in favor of a data format that as far as I can tell
will break most of the parsers that I have seen. I do not think this
is a wise thing to do when there is a standard mechanism provided for
specifying arbitrary data formats that will not break existing
parsers (OSC, DCS, PM, PU1, PU2, ...)
Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available
The Kermit Project @ Columbia University includes Secure Telnet and FTP
http://www.kermit-project.org/ using Kerberos, SRP, and
[EMAIL PROTECTED] OpenSSL. SSH soon to follow.
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
