My 2 cents.

Import: a text stream should detect a line-ending sequence
automatically, or use explicitly specified line-ending sequence, if it
 instructed so.
Text editors should not bother with line end formats: their main
purpose is to correctly display & edit the text, so its much more
important to display it correctly, but quite unimportant in what
format the edited text is stored.
If current text editor uses cr as line ending - i'm fine with that.
Lets then make sure, that it doesn't needs to deal with lf char, since
any lf occurences should be wiped out (converted) before going into
text editor - at text import stage.

Export: at text export, one could always tell , what line endings he
wants to see (by default it could use Smalltalk>>platformLineEndings
).

I don't think that Squeak meant to be used as a generic-purpose text
editor, thus, i don't see real importance in making a smart
import-edit-export cycle which should care about preserving line
ending sequence unchanged. There are a lot of text editors who can do
this and much much more. And squeak text-editing is really suck
comparing to existing word processors.
Lets just face it: Squeak is not text-editing tool and never been.
If one wants a full-featured text editor(s) in squeak - it can build
one, with own import-edit-export cycle. But i don't see why basic
system functionality, which meant to be used just for editing 1-2
lines of source code, should care so much about that.

2009/11/17 Juan Vuletich <juan at jvuletich.org>:
> Hi Nicolas,
>
> Nicolas Cellier wrote:
>>
>> 2009/11/16 Juan Vuletich <juan at jvuletich.org>:
>>
>>>
>>> Hi Nicolas,
>>>
>>> Nicolas Cellier wrote:
>>>
>>>>
>>>> 1] ABOUT RECENT CHANGES IN TRUNK:
>>>>
>>>> st-80 line end policy was really simple (always CR).
>>>> It was the best choice possible as long as staying in Smalltalk world.
>>>> However, I was kind of fed-up with all the hacks for converting
>>>> to/from various line end flavours, half of which not working...
>>>>
>>>> - Since communicating with external world is vital for my own view of
>>>> Squeak
>>>> - Since It is far more simple to handle the zoo of line delimiters in
>>>> Kernel
>>>>  (CompositionScanner / DispalyScanner / String / Stream)
>>>> I just added this support in trunk.
>>>>
>>>> Now, we should be able to import any line termination transparently in
>>>> the image.
>>>> For exporting, nothing changed, we still have to care, no magic here,
>>>> this is driven by external applications requirements.
>>>>
>>>>
>>>
>>> I think you got this one wrong. In Cuis, in a workspace you can tell the
>>> line ending of each line (cr, lf or crlf) and you can actually type all
>>> three. Please try it! Use <Enter>, <Shift-Enter> and <Cmd/Alt-Enter>.
>>> This
>>> way you can edit a text file, and keep it consistent. Otherwise, if you
>>> edit
>>> an existing file that was edited with a Unix or Windows editor and add
>>> CRs
>>> to it it will use more than one convention, without you realizing.
>>> Showing
>>> all in the same way is misleading. Different Strings should look
>>> different
>>> in the editor!
>>>
>>>
>>
>> Hi Juan,
>>
>> 1) Having the possibility to handle mixed conventions does not mean we
>> are forced to use it !
>>
>
> Sure. I didn't say otherwise.
>
>> We can continue to guessLineEndConvention, I did not change this.
>> For writing the file back, either a guess or an explicit requirement
>> might do as well, I did not break anything...
>>
>
> I didn't say you broke something. I say that you're not doing the best. I
> say that the way Cuis does it is better: Show the user the real contents in
> the string, and let him do whatever he wants.
>
>> 2) I have plenty of mixed conventions files in windows world, not
>> created by Squeak.
>> I cannot guessLineEndConvention on such files.
>> Generally Squeak do a real mess and introduce spurious empty lines in this
>> case.
>> The lineEndTransparent is my best option for reading these files.
>>
>
> I think the best is to see all those different line endings, and be able to
> convert them to whatever you want with one keystroke. In Cuis, ctrl-u
> converts all line ends to cr. It is trivial to add options for the other
> conventions.
>
>> 3) For displaying, I think we generally don't care whether a CR, LF or
>> CR-LF is used internally
>> What is the semantic of these characters ?
>>
>
> I don't know. For different people they could have different semantics. The
> system should not make a decision for the user. Computers look really silly
> when they try to be smart...
>
>> To me they all mean the same, no difference, I'm not a typewritter.
>> BUT SEEING CR-LF DISPLAYED SOMETIMES AS TWO LINES AND LF AS NO LINE
>> BREAK IS AWFULL
>>
>
> Indeed. Check Cuis.
>
>> 4) In case we have to compare strings with different lineEndConventions,
>> I suggest the comparing tools make the appropriate conversion first. I
>> don't think this is going to be a real problem.
>>
>
> Sure.
>
>> 5) In case we do care of differences because of external requirements,
>> and we want to visualize them,
>> then a specialized DisplayScanner could display a boxed glyph for CR
>> and LF, and an arrow for TAB.
>> (better than this empty box that doesn't tell which character is under)
>> That should be an option of ParagraphEditor
>>
>
> I disagree. That should be the default behavior, as in Cuis. The user should
> be in command.
>
>> 6) I'll have a look in Cuis (need some time...)
>>
>
> Great!
>
>> Nicolas
>>
>
> Cheers,
> Juan Vuletich
>
>>>> To profit by the new possibilities, just use:
>>>> - (String>>linesDo:) rather than searching indexOf: Character cr
>>>> - (Stream>>nextLine) rather than upTo: Character cr
>>>>
>>>> There might be some LF/CR-LF support lacking here and there (there are
>>>> so many #cr senders...), but that shouldn't be hard to fix.
>>>>
>>>> 2] IMPORTANT NOTE AND QUESTION:
>>>>
>>>> SocketStream>>nextLine does insist on finding a CR-LF pair.
>>>> This is used in some major protocols.
>>>> But I find this abusive, and would like to change the default behavior
>>>> to that of Stream.
>>>> This would be a nice property that a SocketStream behaves like a
>>>> FileStream or an ExternalStream.
>>>> Should I proceed ?
>>>>
>>>> Nicolas
>>>>
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>>
>>>
>>
>>
>>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.