Stan,

> At present, for my own purposes, CrLfFilestream has two advantages over this
> solution. First, with CrLfFilestream, when I edit the file in the
> filelist, the line terminators inserted are consistent with the other
> terminators in the file. Second, CrLfFilestream makes the file appear
> immediately with line breaks where expected, while the encoded text
> solution requires some clicking in the bottom pane before the file is 
> formatted.
> 
> Of course, I understand that CrLfFilestream has one very important
> disadvantage; it cannot display multibyte characters. 

  The other advantage is that MultiByteFileStream subsumes the
CrLfFileStream's feature.  From programmers' point of view, having
redundant classes that do similar things is bad, right?

> I think the cause of MultiByteFileStream not writing at all is the line
>   brevityState == #fullFile ifTrue:
>
> If that is changed to, for example,
>   (#(#fullFile #'iso-8859-2') includes: brevityState) ifTrue:
> then MultiByteFileStreams can be written from the FileList.

  Sorry, I didn't quite understand here.

> I think the cause of MultiByteFileStreams writing with CR instead of
> platform line terminators is that detectLineEndConvention returns LF
> for CrLfFileStream and returns nil for MultiByteFileStream.
> 
>   CrLfFileStream new detectLineEndConvention (print it yields #lf)
>   MultiByteFileStream new detectLineEndConvention (print it yields #nil)

  There is some semantics change.  If you would like a
MultiByteFileStream to detect the platform line end convention, you
need to call #wantsLineEndConversion: first.  For example, 

(MultiByteFileStream new wantsLineEndConversion: true) detectLineEndConvention

returns a symbol.

-- Yoshiki