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 2009/11/20 Peter Hugosson-Miller <[email protected]>: > Exactly! +100 > > FWIW, this us the behaviour of Textpad, my favourite Windoze text > editor. > > -- > Cheers, > Peter. > > On 20 nov 2009, at 01.49, Martin McClure <[email protected]> wrote: > >> IMO, a useful behavior for a text file editor is to: >> >> * On open, detect the line end convention of the file and remember it. >> This is not too hard to do as long as the file is in fact a text file >> (if it's a binary file you shouldn't be using a text editor on it). >> >> * On save, save in the same line end convention that the file >> previously >> had. >> >> * On "save as" provide the opportunity to change the line end >> convention >> as well as the file name. >> >> * New files should default to the platform's line end convention, but >> again be overridable on save. >> >> Regards, >> >> -Martin >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
