Hi Daniel,

So where is this proposal any different / an improvement to the current
status quo? If it were only for the file list I wouldn't have bothered to
get into this discussion at all. It's not the goal that the file list should
deal with line ends flexibly - it's the goal that _all_ applications, tools,
whatever deal with line ends in the most flexible way, and do so by default.
What you are describing below is nothing but the current status quo; you
merely trade using CRLFs>>[new|old|readOnly]FileNamed with
FS>>[smartNew|smartOld|smartReadOnly]FileNamed which (conceptually) seems
even worse to me.

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Daniel Vainsencher
> Sent: Saturday, August 02, 2003 11:33 AM
> To: The general-purpose Squeak developers list
> Cc: 'The general-purpose Squeak developers list'
> Subject: RE: Extending FileList with CrLf
> 
> 
> Yup. Here is my proposal.
> 1. People want to see flexible line endings in the FileList. Make file
> list use CrLfFileStream explicitly, adding some appropriate 
> protocol to
> FileDirectory (#smartFileNamed: or some such). Consider 
> adding a bit of
> state to FileList so that files can be saved either with 
> their original,
> remembered line convention, or the default line convention (see next
> point). Rename CrLfFileStream (since now all file streams can use any
> convention) to SmartFileStream, or some such. Remove the 
> concreteStream
> indirection, so that the protocol used determines precisely 
> what stream
> class is used. This makes it easy to give people examples that will
> magically work regardless of platform convention by using that
> interface.
> 2. Some people want their local OS to determine the default line end
> convention. Move the support for detecting and using the os line
> convention down into FileStream. Vote on whether it should use OS or
> Squeak convention by default.
> 3. We can either determine that .st,.cs files are defined to 
> use crs to
> maintain backward compatibility and squeak-wide compatibility. I'm
> curious if any standard defines this about the format. 
> Anyway, we decide
> this on a per format basis, and adapt the code to use the appropriate
> filestreams and modes.
> 
> Benefits?
> 1. People get the behavior they want in various applications.
> 2. The abstractions of "line ending" and "le auto detection" 
> become more
> separate, so that it is easier for programmer to actually get the
> behavior they want for their programs.
> 3. We have the option of getting the precise and common abstraction
> almost everybody else is using of OS specified, consistent 
> line endings,
> which seems to cause minimal confusion.
> 4. The CrLfFileStream behavior becomes bound to a specific interface
> defined on FileDirectory, so that it is neither more nor less visible
> than StandardFileStream.
> 
> Daniel
> 
> Andreas Raab <andreas.raab at gmx.de> wrote:
> > > If I misunderstand this discussion and am talking at a 
> tangent out of 
> > > ignorance please forgive me.
> > 
> > No, you are restating precisely the arguments that numerous 
> people have made
> > by now. And Daniel is restating precisely the arguments he 
> has made in this
> > thread all along. It's almost funny.
> > 
> > Cheers,
> >   - Andreas
> > 
> > > -----Original Message-----
> > > From: squeak-dev-bounces at lists.squeakfoundation.org 
> > > [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> > > Behalf Of Jimmie Houchin
> > > Sent: Friday, August 01, 2003 11:26 PM
> > > To: The general-purpose Squeak developers list
> > > Subject: Re: Extending FileList with CrLf
> > > 
> > > 
> > > Daniel Vainsencher wrote:
> > > > Jimmie Houchin <jhouchin at texoma.net> wrote:
> > > > 
> > > >>Just for other outside information. Apparently the Python 
> > > group has been 
> > > >>struggling with this issue. I normally don't read about 
> Python, but 
> > > >>occasionally take a peek. :)
> > > >>
> > > >>This PEP has been implemented and is in the latest Python.
> > > >>
> > > >>http://www.python.org/dev/doc/devel/whatsnew/node7.html
> > > > 
> > > > 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.
> > > 
> > > That may be so. But were not Python. :)
> > > Python also has no environment per se.
> > > Python is a language. Squeak is more.
> > > 
> > > >>Talks about the problem and how they decided to handle it 
> > > for Python.
> > > >>
> > > >>Personally, I'm for handling it as elegantly and 
> transparently as 
> > > >>possible. I think that is what most people will expect. I 
> > > understand 
> > > >>Daniel's position. However, Squeak is a high-level environment. 
> > > > 
> > > > I don't know what a "high level environment" is. Squeak 
> > > applications are
> > > > able to provide convinient application level abstractions 
> > > because they
> > > > build on rich lower level abstractions in the class 
> library. I am
> > > > stating that the two abstractions "line ending" and "auto 
> > > detect line
> > > > ending" should remain separate, so that different 
> > > applications can each
> > > > use what it requires.
> > > 
> > > Now Daniel.
> > > Squeak is more than a language.
> > > Squeak is more than the sum of its libraries.
> > > 
> > > Most of us here are consumers of some software written in Squeak.
> > > You can do many things in Squeak as a user without ever 
> > > writing a single 
> > > script or line of code.
> > > 
> > > When I open the World menu and click on file or file list, I 
> > > am a user 
> > > of the environment or that specific application. When I 
> view files on 
> > > Linux it doesn't render line endings correctly. I can't speak 
> > > about Windows.
> > > 
> > > I imagine this goes back to the default behaviour of Squeak.
> > > This is a part of the user experience. It seems to me this is 
> > > what most 
> > > are wanting to be different.
> > > 
> > > As a programmer, feel free to choose the behaviour you want.
> > > 
> > > >>Low-level options are there, but I believe most people 
> > > expect intuitive 
> > > >>responses. I don't expect to open a text document 
> written on the 
> > > >>platform I'm using Squeak on and Squeak not handle it properly.
> > > > 
> > > > We could change the default to be OS line endings - this is 
> > > a reasonable
> > > > change. If you want your text editor to handle any strange 
> > > line endings,
> > > > change your text editor to use an "autodetect line endings" 
> > > mechanism.
> > > 
> > > Why on earth would anybody not want their text editor to 
> handle line 
> > > endings correctly? If the text editor has the ability to 
> > > understand what 
> > > is meant, it should be the very reasonable responsibility 
> of the text 
> > > editor to do the right thing. Why would I want my text editor 
> > > to create 
> > > visual garbage merely to demonstrate that some of the line 
> > > endings came 
> > > from a different platform? So I could manually enter into the 
> > > text and 
> > > delete them and enter correct line endings. Yuck.
> > > 
> > > > However, the default should remain a clean "line ending" 
> > > abstraction,
> > > > without autodetection as it is in Python, C and 
> probably most other
> > > > general purpose languages.
> > > 
> > > But Daniel. We chose _not_ to use those other languages. Part 
> > > of which 
> > > is having better (possibly higher) abstractions. (even as default)
> > > 
> > > You talk about libraries, applications and defaults. Its a 
> > > bad default 
> > > for libraries, but good as a default for applications. 
> Squeak _is_ an 
> > > application. Squeak _is_ an environment. Squeak _has_ a language.
> > > 
> > > I think Squeak should improve on the status of programming.
> > > 
> > > As long as we have to interface and communicate with the 
> > > world outside 
> > > Squeak, including text files, I think we should do it elegantly.
> > > 
> > > Changing a default behaviour in Squeak doesn't remove your or 
> > > anybody's 
> > > ability to use the lower level library. Okay, we can say 
> it merely 
> > > changes were the pain is felt. Since the computing world is not 
> > > consistent in many areas there is some pain. This is pain 
> management. 
> > > Maybe we (I) believe that this reduces the pain in the 
> common usage.
> > > 
> > > I have battled the default behaviour while parsing files. I 
> > > expected one 
> > > thing got another. In the end I chalked it up to my 
> Squeak learning 
> > > curve. But I feel I am not alone in my pain.
> > > 
> > > If I misunderstand this discussion and am talking at a 
> tangent out of 
> > > ignorance please forgive me.
> > > 
> > > Well anyway, I'm over my 2 cents.
> > > 
> > > Jimmie Houchin
> > > 
> > >
>