On Mon, 28 May 2001, Markus Kuhn wrote:
> 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.
AFAICT the only thing ECMA-48 has to say on the subject is:
" In a 7-bit code, the control functions SHIFT-OUT (SO) and SHIFT-IN (SI)
" are permitted to occur
"
" between the CONTROL SEQUENCE INTRODUCER (CSI) and the Final Byte of
" a control sequence,
"
" between the opening delimiter of a control string and the STRING
" TERMINATOR (ST),
"
" between a single-shift control function and its operand.
"
" SO and SI have no effect on the interpretation of a control sequence,
" a control string or the operand of a single-shift control function, but
" they may, indeed, affect the meanings of bit combinations following in
" the data stream.
It's in section 9 "Transformation between 7-bit and 8-bit coded
representations" but for the more stringent requirements of VT100
compatibility all control characters must be available within CSI
sequences.
In the vt102 manual:
http://vt100.net/docs/vt102-ug/chapter5.html#S5.5
" If a control character is received within a sequence, the terminal
" performs the function of the control character, followed by the function
" of the sequence.
> 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.
To a certain extent I would agree but it is probably the best way to do
modal switches because it has a well defined terminator that can safely
be sent 'on spec' (eg as part of the prompt) and don't be confused,
this method of overriding width _is_ still modal.
> 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.
Actually that approach may break the leading zero requirement 5.4.2(f)
because leading 03/00's become significant in that enough of them
could overflow the buffer and prevent the sequence being interpreted.
Even if this approach is only done with private sequences the issue
would apply to VT100 compatibility.
And the requirement you're adding is not within ECMA-48. There is no
requirement on the private sequences except their existance and Annex
D(13) gives you a letout for the action of unknown sequences.
It's VT100 compatibility that requires unknown sequences to be eaten.
It's obvious that you're uncomfortable with requiring a code to be sent
with every character that has it's default width overidden. OTOH I and
others have an aversion to more breakable state at the terminal end.
How about a simplified compromise, I'll put it in a seperate message ...
--
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/
