Extending FileList with CrLf

Andreas Raab andreas.raab at gmx.de
Fri Aug 1 22:46:01 UTC 2003


> 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
> 
> 



More information about the Squeak-dev mailing list