On 20.11.2009 22:30, Nicolas Cellier wrote: > We must separate the matters. > - how should we display the line-feed (independently from their source) > - how should the FileList tool handle various conversions (line end, > encodings,...) > > Old squeak and current Pharo both display an ugly [] box in case there > is a line feed in a String. > > From this point of view, displaying a boxed [lf] in Cuis is already a > big progress :), though I did not follow the same path in trunk. > > Concerning the file tool, +100 for the reasonnable default behavior on read. > But that should not be the sole option. > > For example, I have plenty of mixed line end conventions files. This > is due to people editing the files in heterogeneous environments. You > can judge that this is silly, I perfectly agree, but I can't fight. It > just exists that's a fact. Once you admit that, the bad players are > the applications not handling correctly these mixed conventions files. > Squeak/Pharo are bad players when they try to smartly > detectLineEndConvention, they are not smart at all and introduce > spurious line breaks when they write back with same guessed > convention. > > That's why I HAVE TO be able to CONTROL the read behaviour too, and > not let smart tools decide for me. Transparent line end is one of the > options. > As noticed by Igor, same for encodings of course. > > As for the display, my opinion is that most of the time we just don't > want to see the line endings. > That's why I changed this in trunk to be transparent (more exactly as > transparent if following a cr, as a line break otherwise) > This enables to not care at all for converting external world > input->image in most cases. > I still have to care about converting image->output to external world, > though, I think we all agree on that, so +100 too for the save as > proposals > (hehe, I also have some cases when I do not care at all, because I > have a smart tool chain handling mixed conventions, so again > transparent will be an option). > > In some particular situations we do care and wish to visually control > the line ends. An hex editor is not that fine because we are speaking > of text here, not binary data, and an hex editor generally fails to > interpret the line breaks and leads to hardly readable data. > I personnally use notepad++ and change a display parameter to show > [cr] [lf] boxes. That's what Juan is addressing in Cuis, and I think > it would be simple to incorporate this feature as another option in > the file browser, so we could eventually do it. Anyway, I agree, not > as the default behavior... > > All in all, I think we mostly agree, and should reach a consensus. > > cheers > > Nicolas > +1000 If I'd had time to write a reply to the topic, this post would be i, so thanks for writing it already. :)
Cheers, Henry _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
