This page is part of the web mail archives of SRFI 68 from before July 7th, 2015. The new archives for SRFI 68 contain all messages, not just those from before July 7th, 2015.
Shiro Kawai <shiro@xxxxxxxx> 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