Linefeeds in Squeak source code

Jarvis, Robert P. Jarvisb at timken.com
Tue May 11 19:53:31 UTC 1999


Perhaps if the code which accepts changes and writes them to the .changes
file could be modified to eliminate LF's that would get you to the 99.9%
stage.  Just a thought.

Bob Jarvis
The Timken Company

> -----Original Message-----
> From:	Dan Ingalls [SMTP:Dan.Ingalls at disney.com]
> Sent:	Tuesday, May 11, 1999 3:48 PM
> To:	squeak at cs.uiuc.edu
> Subject:	Linefeeds in Squeak source code
> 
> Folks -
> 
> Right now I'm busy with some other stuff, but I do have an approach to
> suggest that should minimize the problems we have with linefeeds and text
> conversion.  The main situation I want to avoid is where a newbie gets
> Squeak in a manner that adds linefeeds, and can't browse or get updates.
> Being a newbie means you don't even know where to look for the problem,
> and you may not even know how to ask for help from the Squeak list.
> 
> Here's the proposal:
> 
> A.  Each time Squeak starts up, it reads the first 200 characters of each
> of the sources files.  If it finds a LF, then it tells the user that this
> is the case, that it shouldn't be so, that it probably came from
> conversion during download, that it can be fixed, and then asks for
> confirmation to do so.
> 
> If confirmed, Squeak would simply copy the entire file omitting all LFs.
> We have taken pains in the past to ensure that there are no naturally
> occurring LFs in the Squeak sources, so this will work for any Squeak
> release.
> 
> B.  Without coming up with the "right" thing to do for fileOuts (I use a
> Mac and only CRs), we could modify the code for broadcasting updates to
> check for the presence of LFs, and either abort the update or remove the
> LFs on the fly.
> 
> This would seem to solve the most common problems.  The one remaining
> situation I can imagine is that someone works in such a way that they
> introduce LFs in their changes, and then transfers their image in a way
> that introduces LFs in the rest of the sources.  In this case the
> automatic removal would do the wrong thing in the area of the user's
> changes.  This should be rare, but it's the reason for asking to confirm
> the removal in (A) above.
> 
> 	- Dan
> 





More information about the Squeak-dev mailing list