Shiro Kawai <xxxxxx@lava.net> writes:

> If the translate-proc doesn't know about flush-output-stream,
> and a log message happen to end with a non-ascii character,
> it won't write out the closing escape sequence ESC '(' 'B'
> at the end of log message, for it doesn't know if more non-ascii
> character is coming or not.   If the application crashes then,
> the log file remains in the non-ascii state.  Subsequent run
> of the applicaion starts adding messages, assuming the file begins
> with ascii state---resulting that the first ascii portion of
> the new message becomes illegible.
>
> I admit this is just a bad design.  Still, the character encoding
> stuff is so complicated that I appreciate anything that adds
> more certainty and control.

OK, I think I understand now.  (Many thanks for all the explanation,
BTW---it's extremely helpful to me.)

Now, this flushing business makes me a little concerned: What you're
proposing means my output data is different depending on when I call
flush.  However, I always thought of this invariant as pretty
fundamental to what flush does---that it does not change the data.

It seems what you really should do to solve your problem is send a
message to the translator to insert the closing escape sequence into
the output stream, and have the *translator* flush after it has
encountered the message and written the closing sequence.  You could
just use U+0003 (END OF TEXT) or something for that purpose.  Would
this be reasonable?

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla