>>>>>> 
>>>>>> CRLF Handling
>>>>>> -------------
>>>>>> CR and LF are now treated interchangeably in rendering. Both cause a 
>>>>>> line break and both are not displayed. Various line related methods have 
>>>>>> been updated to deal with both CR and LF.
>>>> 
>>>> I imagine that this were fixes of nicolas
>>>> 
>>> 
>>> Only the line splitting stuff is in Pharo (it was started in Pharo).
>>> I did not port the transparent displaying of line feeds to Pharo yet.
>>> Are you interested ?
>> 
>> what is it?
>> 
> 
> It is a change to render LF just like CR in DisplayScanner & co, with
> a hack for CR-LF pairs, instead of an ugly box [].
> RATIONALE: most times we don't care how the line ending is encoded, we
> just want it to be rendered correctly.
> 
> Note that juan did modify more a less the same methods in Cuis but
> added a visible boxed [lf] glyph instead of transparent one.
> RATIONALE: In squeak, all line endings should have been converted to
> CR already, except in some cases when we care for LF.
> In such cases, we would like to control visually the presence:
> - of LF (a [lf] is displayed at end of line)
> - or of CR-LF (a [lf] is displayed at beginning of next line).
> 
> These are two different approaches of the same problem: whatever our
> ingeniousity, we just can't eradicate LF...

If we think that we could eradicate lf I think that it would be nice to see [lf]
because if we paste the code from pharo to any other tools it would be good
to see that we are not consistent. Then we could also know that this is the 
time 
to run an eradicating script once more on the complete source code.




_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to