On Wed, 8 Jun 2005, bear wrote:

>
>
>On Tue, 7 Jun 2005, Shiro Kawai wrote:
>
>>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.

> This argues that the translate-proc should "wrap" the output
> stream, so that it always knows about flush messages.  It does
> what it must do, then passes the "flush" message on to the
> primitive output stream.  Right?

Sorry to follow-up to my own post, but there's another
possibility I didn't think of initially;

Translate-chars and flush-translator could be "callbacks"
handed to the I/O port on opening, and the I/O port code
would be responsible for calling them appropriately when
reading/writing or flushing, respectively.  They'd have
to be exported from a closure together, with a scope that
allows them to access common datastructures not visible
to other code, but that's not too hard.

				Bear