Ok I read everything.
Igor I agree with you about not showing tags but the system still show []
and let me import [lf] files and fucked up my code. Each time I save VW code to
import
it into pharo I have to run some scripts to clean that.
Here is what I understood
- could we try to make sure that when something is loaded in the image
it by default follow image convention?
For example I fill in a cs that contains lf
I should get something consistent in the image
- would be nice to see [lf] instead of [] and remove all of them from
the image
- for filelist would be nice to see and be able to change the end of
the line character
- Now I was wondering what is the status at the level of the stream?
Ie can I load a file which has lf and say stream convertLFToCr?
Stef
> 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
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
