2009/11/30 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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.
Yes, but why should we care of cr/lf presence inside Smalltalk as long as they are interpreted/rendered transparently? The problem is only when we want to export to external world. Nicolas
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project