At the origin, Smalltalk was all CR Then some conversions were introduced at input/output from/to external world. Then we made some of our tools line-Ending-Zoo-Agnostic (for example, text rendering now supports CR, LF, or CR-LF). This was questionnable, because we injected a bit more complexity in the image, rather than segregating the complexity at the interfaces. But I think it was a good change, because we had more and more interfaces, and more and more patches/workarounds to handle. And finally, being line-Ending-Zoo-Agnostic costs a bit, but not that much. The most questionnable feature is the presence of mixed convention in image and the impact on simple String comparison... Some conversion is still required. In any case, what we must avoid is massively replace cr with lf in our source code. What I recommand is using (aStream nextLine) rather than (aStream upTo: Character cr). And we should probably replace most of the (aStream cr) with (aStream newLine) in our tools. ( except in rare places where with really want to control cr/lf because it is protocol specific ) This way, cr/lf will be an implementation detail that we can rapidly switch with a Preference/Setting, some OS-Aware environment variable (some class variable set at image startup to avoid asking os colour at each newLine), or just hardcode. Even if that does not completely eliminate the need for converting some input/output... 2014-07-25 12:03 GMT+02:00 Stephan Eggermont <stephan@stack.nl>:

Sean wrote:

...

git was mentioned (which is my use-case too). Since the community is using it more and more, it might make sense to have a default, no?

Not AFAIK. You are supposed to tell git and github what to use.

http://stackoverflow.com/questions/170961/whats-the-best-crlf-handling-strat...

Stephan