Robert de Bath wrote on 2001-05-28 09:34 UTC:
> > 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.
Please quote the exact and complete phrase in ECMA that you think
contradicts with what I said, if you think there is any, because I
really can't find a reference for what you claim.
Very clearly, a control function consists only of sequences of the form
CSI [0-\?]*[ -/]*[@-~]
and therefore does not allow a C0/C1 inside its parameter string.
Resetting the control function parser as soon as a character outside the
above egexp is found seems the most prudent approach here. (Note that
things like XON/XOFF are handled one layer below in the serial-line
driver or equivalent and do not interfere here.)
Any other semantics would be rather unpleasant, as data corruption could
easily extend over line boundaries. There is one specific code CAN
reserved that only aborts ESC sequences and does nothing else, but that
does not imply that other C0 character can occur inside a control
function that starts with CSI.
> 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.
I find DCS *highly* unpleasant in this context for the stated reasons
and I will not draft a proposal based on it as I would consider that bad
engineering.
If people who want to implement SCW first have to bring their control
sequence parsers a bit more into conformance with ECMA-48, then be it
so. I see nothing bad here, the changes can be implemented in < 5 person
hours in most implementations that I can think of. It would seem a
perfectly legitimate approach to load an entire control function first
into a buffer until the final byte has been received (in particular if
the first parameter string byte was 03/12-03/15), at which point a
suitable parameter string parser is invoked.
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/
