Göran,

> Btw, yesterday I was staring at the MultiByteFileStream stuff and...
> well, IMHO it would have been better *for me* (other users may have
> other stories to tell) if the default was binary and not ascii. The
> principle of least surprise. If I open a filestream and don't tell it
> *anything*, then I would expect it to just feed me the bits and bytes -
> as Strings or ByteArrays, but not doing any conversions or line end
> mumbo jumbo or any other non expected "nice things". An example of this
> is inspecting a file in the file list - I really appreciated the fact
> that filelist didn't do *any* conversion on the stuff it showed me - now
> it does. And I also wonder where the hex view went... anyway:

  In 3.9a 7021 and 3.8-6665, we have "view as hex" item in the file
list content pane menu.  Also, we have "view as encoded text" to
choose different encoding.

  But, I agree, at least the file list has to do sensible stuff
because people may edit the content and save it.  The default encoding
for the file list content pane should be non-conversion, as there can
be some binary files (or can get it from a preference).  And once the
user sets to certain encoding for a file, the file somehow remember it
(perhaps until the file list instance is closed) and use the encoding
for subsequent actions.

  Also, it might make more sense that setting the converter to nil
sets it to Latin1TextConverter (NullTextConverter), as you expected.

-- Yoshiki