Practical problems:
I used to have a Celeste DB. I work in Linux most days. I go to ESUG
with Windows laptop. On it I start another DB. I come back and try to
merge. Blech, my files are not bit compatible because they happened to
have been created on different OSes... And because my images used CrLfFS
by default, I wasn't even aware of this.

After that, I stopped using it. 

Philosophically:
When you say that "text" automatically means one specific mode, in which
in-the-image representations do not match in-the-file representations,
you are ignoring other possibilities. I should be able to specify text
behavior, and decide what mapping I want exactly, but the default
mapping should be the transparent one - the identity mapping.

Text vs binary (determining, for example, the question "is nextLine
defined?") is a prior question to "line ending convention" which is
defined for text mode. 

To me, CrLfFS as a default is only different in degree from having as a
default a stream that draws the text into a large rectangular bitmap,
and writes it as a JPEG. Its effects may be recoverable (assuming nobody
puts strange artefacts into it), but it loses information which may be
important, and is an unobvious choice of representation, which will
overall add confusion, not reduce it.

BTW, I think we are using the word "transparent" with different
meanings. For me, something that has external effects (files
incompatible across platforms) is not truly transparent, even if it
seems so for a couple of months, or to someone very used to it.

Daniel

Lex Spoon <lex at cc.gatech.edu> wrote:
> Daniel Vainsencher <danielv at netvision.net.il> wrote:
> > [Using CrLf by default]
> > I strongly disagree.
> 
> Could you please elaborate on your stance?  If we switch over then a
> practical problem will be solved: people who don't use CrLfFS write code
> that breaks under CrLFFS, and there's no need for it.  Further, most
> people who don't use Mac's would like to have the functionality.
> 
> Since there are practical advantages, we should only stop due to
> practical disadvantages, or to very clear philosophical problems.  Your
> philisophical issue are unclear to me, though I will try to respond to
> them as best I can.  You mention no practical problems.
> 
> 
> > How files are interpreted, at any level, should not
> > be a system wide decision made by low level streaming classes. It should
> > be an application level decision.
> 
> It would be an application decision.  The application states whether
> it wants binary or text mode, and it gets what it asks for.  The debate
> is about what, exactly, "text" mode should ask for.
> 
> As things stand, people keep proposing replacing this or that with an
> explicit use of CrLfFileStream.  This shows that it's a commonly
> requested behavior in practice.  I claim that every single "text file"
> Squeak uses should get this functionality, and thus we may as well make
> it the default.  If you care about the exact line end convention that a
> file uses, then you are trying to control individual bytes and thus you
> aren't really using a "text file" after all.  For example, PDF's are not
> text files despite using a lot of ASCII in them.
> 
> 
> 
> 
> > IMO, the fact that CrLfStream tries to be quite subtle about what it
> > does is a point against as a default, though it might be useful for 
> > a specific user or application. The default behavior should be simple 
> > and transparent.
> 
> Why do you say it is subtle?  It maps CR, LF, and CRLF to CR, if the
> file is in text mode.  That's all.
> 
> It's simple and it's transparent.  Additionally, it's useful and it's
> what people usually want.  These are great things for a default,
> so let's make it the default.
> 
> 
> Lex