Daniel,

Sigh. When will you actually start listening to what is said by all the
people involved in this thread? Every time you write one of those "don't
define a policy across all application" thingies you imply that clients are
unable to change the policy. How often has everyone to repeat that this is
simply false? Defining a _default_ policy does not mean that any application
which cares cannot change it. 

The point about defaults is to capture the majority of use cases. And deny
it as long as you want, in the vast majority of the cases where we deal with
text, we _want_ a smart translation of line endings. Sure, every
"application" could set this on its own, but then, why not just make it the
default.

This is really silly. We're repeating the same arguments over and over.

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 6:24 PM
> To: The general-purpose Squeak developers list
> Cc: 'The general-purpose Squeak developers list'
> Subject: RE: Extending FileList with CrLf
> 
> 
> That's the thing - I don't agree that you really want to 
> define any such
> policy across all applications, by fiat. What I am suggesting 
> is that we
> actually implement the specific policies that make sense for different
> applications. FileList is the obvious one. If that's what makes sense,
> we can change every single application currently in the image to use
> CRLFFS. As long as applications that do conversions make it 
> explicit in
> their code.
> 
> What's the improvement? people get the behavior they want in
> applications. I thought that's what you were after. Just to clarify, I
> am proposing to implement the change suggested in in all 
> interfaces for
> file opening. Concretely, this means in FileDirectory, too.
> 
> Daniel
> 
> Andreas Raab <andreas.raab at gmx.de> wrote:
> > 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
> > > > > 
> > > > >
> > >
>