[Can we agree that filing in code should use CR/LF autodetection]
Sure. There is a small point that needs to be decided of how to handle
files that include literal strings that include line endings. Are these
translated or not? if they are translated, that could mean some
difficulties. I guess this is one advantage to all those languages that
use escape codes to represeting literal line endings (\n and such). But
I certainly wouldn't care much.

[U being explicit]
I don't know what exact kinds of backwards compatibility they have in
mind. My interest is not in backwarks compatibility (with previous
versions of squeak). My interest is in sideways compatibility, which
includes both interoperation with different non-squeak applications, of
which many do distinguish between crs and lfs, and also includes using
the conventional sense of a cencept. I don't mind having to work to
explain to a C programmer how Squeaks important concepts are actually
better, however "alien", but to have to explain we have our own ideas
about line endings doesn't seem worth the weight.

Daniel

"Richard A. O'Keefe" <ok at cs.otago.ac.nz> wrote:
> Daniel Vainsencher <danielv at netvision.net.il> quoted
> mention of the Python PEP for "Universal Newline Support" but wrote:
> 
> 	Note that they implemented the library so it requires an explicit
> 	parameter for it to enter "universal" mode. That is exactly what I'm
> 	proposing we do. This is not what CLFS does.
> 	
> Note also what the PEP says in the very next paragraph:
>     Universal newline support is also used when importing modules and
>     when executing a file with the execfile() function.  This means that
>     Python modules can be shared between all three operating systems without
>     needing to convert the line-endings.
> 
> It's also worth reading the rational in the actual PEP itself.
> There are basically two problems:
> (1) backwards compatibility (not something Squeak is known for, so not an
>     issue in this mailing list)
> (2) the low-level code in Python wasn't defined with this in mind, so there
>     is too much code that does writing to C FILE* and cannot therefore be
>     told to use "u" convention; this means that they can't figure out how
>     to do "wu".  This again is NOT a problem that Squeak faces.
> In short, none of the reasons for Python having "ru" explicit and no
> "r+u" or "au" or "wu" seem to apply to Squeak; we are free to do the
> right thing.
> 
> One clear emphasis in the Python PEP is that they would like to have
> Python source code in a file system that can be mounted by operating
> systems with differeng end-of-line conventions and just have it work;
> the analogue for Squeak would at a minimum be having change sets "just
> work" whatever their end of line convention.
> 
> Is it possible to reach agreement that change sets should "just work"
> no matter what end of line convention they use?  This question can be
> separated from the issue of what happens when programmers open files
> themselves.