About end of line convention

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

About end of line convention

Stéphane Ducasse
Hi nicolas

I was dicussing today with juan vuletich about the management of end of line convention and I think that
he is right. When we edit a file we should be in control about that we want to have.
In CUIS when you edit a file you can decide the convention or change it.
He told me that in the squeak world people were pushing that the end of line is controlled by the platform.
My point of view on this is :
        - when I manipulate the text object may be we should have the platform convention.
        - when I edit a file I should get the control because I may want to edit a file on mac with unix convention.

So nicolas I saw that you pushed a slice about fixing end of line.
What is the design behind it?

Stef
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About end of line convention

Igor Stasenko
2009/11/20 Stéphane Ducasse <[hidden email]>:
> Hi nicolas
>
> I was dicussing today with juan vuletich about the management of end of line convention and I think that
> he is right. When we edit a file we should be in control about that we want to have.
> In CUIS when you edit a file you can decide the convention or change it.

The way how CIUS solves this shown at screenshot.

My humble question:
if i created a text file, what you think is more important to me:
  - being able to clearly read the text
  - or being able to see all control characters which may differ from
OS to OS???

My line of argumentation is, that text editor should serve for editing
a text, but not some sort of binary-mode editing
where text is a mix of usual symbols and non-human stuff, which having
meaning only to computer.

If i would want to see a binary contents of file, i use hex dump
display/edit, but not text editor.
(see another attachment)

Use right tool for things you do. By making a single tool for serving
everything - as result you getting a horrific & complex monster
without any means how to manage it and improve.

> He told me that in the squeak world people were pushing that the end of line is controlled by the platform.

This is not correct.
I am pushing the idea, that text editor should serve to edit and
display text, and don't care about preserving or dealing with
different line-end conventions. Instead, import should deal with
normalizing the input to a form, edigible by editor, and then export
layer (file-out or whatever) may be instructed to save edited file
using one or other line-ends, but editor should use own convention(s)
and free to choose own ways how internally store the edited text.

> My point of view on this is :
>        - when I manipulate the text object may be we should have the platform convention.
>        - when I edit a file I should get the control because I may want to edit a file on mac with unix convention.
>
> So nicolas I saw that you pushed a slice about fixing end of line.
> What is the design behind it?
>

Stef, you can always read a full discussion about it on squeak-dev archives.
http://n4.nabble.com/support-of-various-line-ends-in-trunk-td622338.html#a622338

> Stef
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

text.txt (90 bytes) Download Attachment
cuis-editor.png (9K) Download Attachment
hexdump.png (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: About end of line convention

Stéphane Ducasse
>
> The way how CIUS solves this shown at screenshot.
>
> My humble question:
> if i created a text file, what you think is more important to me:
>  - being able to clearly read the text
>  - or being able to see all control characters which may differ from
> OS to OS???

sorry but you are wrong.
I saw how this is done in CUIS and if you want to see the end line character
you can see them, else not.
I'm often burned with not having that and I think that his solution is cool.

> My line of argumentation is, that text editor should serve for editing
> a text, but not some sort of binary-mode editing
> where text is a mix of usual symbols and non-human stuff, which having
> meaning only to computer.

No

> If i would want to see a binary contents of file, i use hex dump
> display/edit, but not text editor.
> (see another attachment)

No

> Use right tool for things you do. By making a single tool for serving
> everything - as result you getting a horrific & complex monster
> without any means how to manage it and improve.

No

>
>> He told me that in the squeak world people were pushing that the end of line is controlled by the platform.
>
> This is not correct.
> I am pushing the idea, that text editor should serve to edit and
> display text, and don't care about preserving or dealing with
> different line-end conventions.

Then you did not got burn enough by moving files between OSes
I regularly spent time with tr on unix just to clean such kind of things.

> Instead, import should deal with
> normalizing the input to a form, edigible by editor, and then export
> layer (file-out or whatever) may be instructed to save edited file
> using one or other line-ends, but editor should use own convention(s)
> and free to choose own ways how internally store the edited text.
>
>> My point of view on this is :
>>        - when I manipulate the text object may be we should have the platform convention.
>>        - when I edit a file I should get the control because I may want to edit a file on mac with unix convention.
>>
>> So nicolas I saw that you pushed a slice about fixing end of line.
>> What is the design behind it?
>>
>
> Stef, you can always read a full discussion about it on squeak-dev archives.
> http://n4.nabble.com/support-of-various-line-ends-in-trunk-td622338.html#a622338

No time for that now.

>
>> Stef
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
> <text.txt><cuis-editor.png><hexdump.png>_______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About end of line convention

Igor Stasenko
2009/11/20 Stéphane Ducasse <[hidden email]>:

>>
>> The way how CIUS solves this shown at screenshot.
>>
>> My humble question:
>> if i created a text file, what you think is more important to me:
>>  - being able to clearly read the text
>>  - or being able to see all control characters which may differ from
>> OS to OS???
>
> sorry but you are wrong.
> I saw how this is done in CUIS and if you want to see the end line character
> you can see them, else not.
> I'm often burned with not having that and I think that his solution is cool.
>
>> My line of argumentation is, that text editor should serve for editing
>> a text, but not some sort of binary-mode editing
>> where text is a mix of usual symbols and non-human stuff, which having
>> meaning only to computer.
>
> No
>
>> If i would want to see a binary contents of file, i use hex dump
>> display/edit, but not text editor.
>> (see another attachment)
>
> No
>
>> Use right tool for things you do. By making a single tool for serving
>> everything - as result you getting a horrific & complex monster
>> without any means how to manage it and improve.
>
> No
>
>>
>>> He told me that in the squeak world people were pushing that the end of line is controlled by the platform.
>>
>> This is not correct.
>> I am pushing the idea, that text editor should serve to edit and
>> display text, and don't care about preserving or dealing with
>> different line-end conventions.
>
> Then you did not got burn enough by moving files between OSes
> I regularly spent time with tr on unix just to clean such kind of things.
>

Trust me, i burnt to the point that i don't want to see or hear about
them again in my life. And Juan's editor displaying 'lf' glyphs is
like 'wellcome back, to hell'.

Squeak's text editor allows you to do some formatting, like changing
font, emphasis, color and more special things like links etc..
And once you changing text using this, you can't represent it as
plaing text without losing formatting information, and from that point
preserving line ends becoming too minor issue comparing to fact that
you can't preserve formatting.

As to me, from this side, a text editor behaves like html renderer,
while displaying control characters is analoguous to displaying html
source instead of rendering it. Now tell me, have you seen html
renderer , which instead of rendering page - showing you tags?

Or if you prefer to see html source, then it is logical to diplay all
other kinds of formatting with plain text (by using some kind of
markup), instead of reflecting them visually. No?

And then, don't you think that rendering html and displaying html is
done using different tools, because obviously it is two different
representations of same document. And nobody mixing them (you don't
see any tags when browsing, while can see them when looking at
source), while Juan's modification looks like a mixture of two
different modes - 'raw' mode, when you can see source and rendering
mode - when you see the designed document.

Such kind of mixture is awfully wrong. So, if you want to see line
feeds in text, then get rid of text formatting features first,
or make two SEPARATE TOOLS, each specialized on different displaying mode.

>> Instead, import should deal with
>> normalizing the input to a form, edigible by editor, and then export
>> layer (file-out or whatever) may be instructed to save edited file
>> using one or other line-ends, but editor should use own convention(s)
>> and free to choose own ways how internally store the edited text.
>>
>>> My point of view on this is :
>>>        - when I manipulate the text object may be we should have the platform convention.
>>>        - when I edit a file I should get the control because I may want to edit a file on mac with unix convention.
>>>
>>> So nicolas I saw that you pushed a slice about fixing end of line.
>>> What is the design behind it?
>>>
>>
>> Stef, you can always read a full discussion about it on squeak-dev archives.
>> http://n4.nabble.com/support-of-various-line-ends-in-trunk-td622338.html#a622338
>
> No time for that now.
>
>>
>>> Stef
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>> <text.txt><cuis-editor.png><hexdump.png>_______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About end of line convention

Philippe Marschall-2-3
In reply to this post by Stéphane Ducasse
Stéphane Ducasse wrote:

> Hi nicolas
>
> I was dicussing today with juan vuletich about the management of end of line convention and I think that
> he is right. When we edit a file we should be in control about that we want to have.
> In CUIS when you edit a file you can decide the convention or change it.
> He told me that in the squeak world people were pushing that the end of line is controlled by the platform.
> My point of view on this is :
> - when I manipulate the text object may be we should have the platform convention.
> - when I edit a file I should get the control because I may want to edit a file on mac with unix convention.
>
> So nicolas I saw that you pushed a slice about fixing end of line.
> What is the design behind it?

End of line convention in which context? The changes file? File outs?
File streams?

Cheers
Philippe


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About end of line convention

Stéphane Ducasse
It was more on file streams or text when you edit a file.
In particular this was in context of
        http://code.google.com/p/pharo/issues/detail?id=1458       

Because before integrating it I wanted to know what it was about.

Stef

On Nov 20, 2009, at 6:09 PM, Philippe Marschall wrote:

> Stéphane Ducasse wrote:
>> Hi nicolas
>>
>> I was dicussing today with juan vuletich about the management of end of line convention and I think that
>> he is right. When we edit a file we should be in control about that we want to have.
>> In CUIS when you edit a file you can decide the convention or change it.
>> He told me that in the squeak world people were pushing that the end of line is controlled by the platform.
>> My point of view on this is :
>> - when I manipulate the text object may be we should have the platform convention.
>> - when I edit a file I should get the control because I may want to edit a file on mac with unix convention.
>>
>> So nicolas I saw that you pushed a slice about fixing end of line.
>> What is the design behind it?
>
> End of line convention in which context? The changes file? File outs?
> File streams?
>
> Cheers
> Philippe
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About end of line convention

Nicolas Cellier
2009/11/20 Stéphane Ducasse <[hidden email]>:
> It was more on file streams or text when you edit a file.
> In particular this was in context of
>        http://code.google.com/p/pharo/issues/detail?id=1458
>
> Because before integrating it I wanted to know what it was about.
>
> Stef
>

Hi Stephane,

These changes just make it possible to handle various line delimiters
for splitting lines in a String.

Discussion was lengthy in trunk about whether or not these various
line delimiters should have made their path inside the image.
Some would prefer to stick to simple st-80 cr-only handling in image
and carry ALL the conversions at read/write to the complex external
world.
The rationale is that complexity should not enter the image.

My POV differs.

1) because handling cr-lf-crlf in image is not that complex (judge how
complex is the new code versus the old one)
2) because it is not CPU intensive (The line splitting methods were
not optimized, thus I reduced the cost of splitting, and therefore, I
reject the argument that it does matter that much)
3) because making the right decision about conversion can depend on
applications and can be complex, that's why it should ultimately be in
the hands of programmer.

I see no contradiction in using detectLineEndConventions in Pharo tools.
Though the current algorithm fail to handle mixed-conventions files
correctly, that's a good default policy.
But this simple trick can NOT handle ALL the cases (the
mixed-conventions is an example).

A universal line end converter fitting all possible use cases does not
exist and would be more than complex.
Let the grown up programmer decide what better fits his application
and provide decent tools to him (her).

If you decide to reject these modifications, then please revert
http://code.google.com/p/pharo/issues/detail?id=1356 for consistency.

cheers

Nicolas


> On Nov 20, 2009, at 6:09 PM, Philippe Marschall wrote:
>
>> Stéphane Ducasse wrote:
>>> Hi nicolas
>>>
>>> I was dicussing today with juan vuletich about the management of end of line convention and I think that
>>> he is right. When we edit a file we should be in control about that we want to have.
>>> In CUIS when you edit a file you can decide the convention or change it.
>>> He told me that in the squeak world people were pushing that the end of line is controlled by the platform.
>>> My point of view on this is :
>>>      - when I manipulate the text object may be we should have the platform convention.
>>>      - when I edit a file I should get the control because I may want to edit a file on mac with unix convention.
>>>
>>> So nicolas I saw that you pushed a slice about fixing end of line.
>>> What is the design behind it?
>>
>> End of line convention in which context? The changes file? File outs?
>> File streams?
>>
>> Cheers
>> Philippe
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About end of line convention

Stéphane Ducasse
Thanks
It makes sense to me.
I like to have a good default and give the power to the programmer.

Stef

On Nov 20, 2009, at 7:39 PM, Nicolas Cellier wrote:

> 2009/11/20 Stéphane Ducasse <[hidden email]>:
>> It was more on file streams or text when you edit a file.
>> In particular this was in context of
>>        http://code.google.com/p/pharo/issues/detail?id=1458
>>
>> Because before integrating it I wanted to know what it was about.
>>
>> Stef
>>
>
> Hi Stephane,
>
> These changes just make it possible to handle various line delimiters
> for splitting lines in a String.
>
> Discussion was lengthy in trunk about whether or not these various
> line delimiters should have made their path inside the image.
> Some would prefer to stick to simple st-80 cr-only handling in image
> and carry ALL the conversions at read/write to the complex external
> world.
> The rationale is that complexity should not enter the image.
>
> My POV differs.
>
> 1) because handling cr-lf-crlf in image is not that complex (judge how
> complex is the new code versus the old one)
> 2) because it is not CPU intensive (The line splitting methods were
> not optimized, thus I reduced the cost of splitting, and therefore, I
> reject the argument that it does matter that much)
> 3) because making the right decision about conversion can depend on
> applications and can be complex, that's why it should ultimately be in
> the hands of programmer.
>
> I see no contradiction in using detectLineEndConventions in Pharo tools.
> Though the current algorithm fail to handle mixed-conventions files
> correctly, that's a good default policy.
> But this simple trick can NOT handle ALL the cases (the
> mixed-conventions is an example).
>
> A universal line end converter fitting all possible use cases does not
> exist and would be more than complex.
> Let the grown up programmer decide what better fits his application
> and provide decent tools to him (her).
>
> If you decide to reject these modifications, then please revert
> http://code.google.com/p/pharo/issues/detail?id=1356 for consistency.
>
> cheers
>
> Nicolas
>
>
>> On Nov 20, 2009, at 6:09 PM, Philippe Marschall wrote:
>>
>>> Stéphane Ducasse wrote:
>>>> Hi nicolas
>>>>
>>>> I was dicussing today with juan vuletich about the management of end of line convention and I think that
>>>> he is right. When we edit a file we should be in control about that we want to have.
>>>> In CUIS when you edit a file you can decide the convention or change it.
>>>> He told me that in the squeak world people were pushing that the end of line is controlled by the platform.
>>>> My point of view on this is :
>>>>      - when I manipulate the text object may be we should have the platform convention.
>>>>      - when I edit a file I should get the control because I may want to edit a file on mac with unix convention.
>>>>
>>>> So nicolas I saw that you pushed a slice about fixing end of line.
>>>> What is the design behind it?
>>>
>>> End of line convention in which context? The changes file? File outs?
>>> File streams?
>>>
>>> Cheers
>>> Philippe
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About end of line convention

Nicolas Cellier
In reply to this post by Igor Stasenko
2009/11/20 Igor Stasenko <[hidden email]>:

> 2009/11/20 Stéphane Ducasse <[hidden email]>:
>>>
>>> The way how CIUS solves this shown at screenshot.
>>>
>>> My humble question:
>>> if i created a text file, what you think is more important to me:
>>>  - being able to clearly read the text
>>>  - or being able to see all control characters which may differ from
>>> OS to OS???
>>
>> sorry but you are wrong.
>> I saw how this is done in CUIS and if you want to see the end line character
>> you can see them, else not.
>> I'm often burned with not having that and I think that his solution is cool.
>>
>>> My line of argumentation is, that text editor should serve for editing
>>> a text, but not some sort of binary-mode editing
>>> where text is a mix of usual symbols and non-human stuff, which having
>>> meaning only to computer.
>>
>> No
>>
>>> If i would want to see a binary contents of file, i use hex dump
>>> display/edit, but not text editor.
>>> (see another attachment)
>>
>> No
>>
>>> Use right tool for things you do. By making a single tool for serving
>>> everything - as result you getting a horrific & complex monster
>>> without any means how to manage it and improve.
>>
>> No
>>
>>>
>>>> He told me that in the squeak world people were pushing that the end of line is controlled by the platform.
>>>
>>> This is not correct.
>>> I am pushing the idea, that text editor should serve to edit and
>>> display text, and don't care about preserving or dealing with
>>> different line-end conventions.
>>
>> Then you did not got burn enough by moving files between OSes
>> I regularly spent time with tr on unix just to clean such kind of things.
>>

Hi Igor

>
> Trust me, i burnt to the point that i don't want to see or hear about
> them again in my life. And Juan's editor displaying 'lf' glyphs is
> like 'wellcome back, to hell'.
>

Just what [] box are currently :) but a bit more informative.
Don't flame me, I don't support this feature as a reasonnable default.

> Squeak's text editor allows you to do some formatting, like changing
> font, emphasis, color and more special things like links etc..
> And once you changing text using this, you can't represent it as
> plaing text without losing formatting information, and from that point
> preserving line ends becoming too minor issue comparing to fact that
> you can't preserve formatting.
>
> As to me, from this side, a text editor behaves like html renderer,
> while displaying control characters is analoguous to displaying html
> source instead of rendering it. Now tell me, have you seen html
> renderer , which instead of rendering page - showing you tags?
>

+1
So I'm happy to notice you should agree on my modification for
rendering linefeed transparently in trunk.

> Or if you prefer to see html source, then it is logical to diplay all
> other kinds of formatting with plain text (by using some kind of
> markup), instead of reflecting them visually. No?
>
> And then, don't you think that rendering html and displaying html is
> done using different tools, because obviously it is two different
> representations of same document. And nobody mixing them (you don't
> see any tags when browsing, while can see them when looking at
> source), while Juan's modification looks like a mixture of two
> different modes - 'raw' mode, when you can see source and rendering
> mode - when you see the designed document.
>
> Such kind of mixture is awfully wrong. So, if you want to see line
> feeds in text, then get rid of text formatting features first,
> or make two SEPARATE TOOLS, each specialized on different displaying mode.
>

Good sense of logic, that's a smart demonstration.
But we have to be pragmatic too.
If we limit this feature to poor text editors (character files), the
demonstration about rich text does not really apply.
Be it an option or a separate tool does not really matter. Notepad++
and lot of other string editors have this as an option.
As long as it is an option in FileList tool and not the main
behaviour, I think you could tolerate it, couldn't you ?

cheers

Nicolas

>>> Instead, import should deal with
>>> normalizing the input to a form, edigible by editor, and then export
>>> layer (file-out or whatever) may be instructed to save edited file
>>> using one or other line-ends, but editor should use own convention(s)
>>> and free to choose own ways how internally store the edited text.
>>>
>>>> My point of view on this is :
>>>>        - when I manipulate the text object may be we should have the platform convention.
>>>>        - when I edit a file I should get the control because I may want to edit a file on mac with unix convention.
>>>>
>>>> So nicolas I saw that you pushed a slice about fixing end of line.
>>>> What is the design behind it?
>>>>
>>>
>>> Stef, you can always read a full discussion about it on squeak-dev archives.
>>> http://n4.nabble.com/support-of-various-line-ends-in-trunk-td622338.html#a622338
>>
>> No time for that now.
>>
>>>
>>>> Stef
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>> <text.txt><cuis-editor.png><hexdump.png>_______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About end of line convention

Igor Stasenko
2009/11/20 Nicolas Cellier <[hidden email]>:

> 2009/11/20 Igor Stasenko <[hidden email]>:
>> 2009/11/20 Stéphane Ducasse <[hidden email]>:
>>>>
>>>> The way how CIUS solves this shown at screenshot.
>>>>
>>>> My humble question:
>>>> if i created a text file, what you think is more important to me:
>>>>  - being able to clearly read the text
>>>>  - or being able to see all control characters which may differ from
>>>> OS to OS???
>>>
>>> sorry but you are wrong.
>>> I saw how this is done in CUIS and if you want to see the end line character
>>> you can see them, else not.
>>> I'm often burned with not having that and I think that his solution is cool.
>>>
>>>> My line of argumentation is, that text editor should serve for editing
>>>> a text, but not some sort of binary-mode editing
>>>> where text is a mix of usual symbols and non-human stuff, which having
>>>> meaning only to computer.
>>>
>>> No
>>>
>>>> If i would want to see a binary contents of file, i use hex dump
>>>> display/edit, but not text editor.
>>>> (see another attachment)
>>>
>>> No
>>>
>>>> Use right tool for things you do. By making a single tool for serving
>>>> everything - as result you getting a horrific & complex monster
>>>> without any means how to manage it and improve.
>>>
>>> No
>>>
>>>>
>>>>> He told me that in the squeak world people were pushing that the end of line is controlled by the platform.
>>>>
>>>> This is not correct.
>>>> I am pushing the idea, that text editor should serve to edit and
>>>> display text, and don't care about preserving or dealing with
>>>> different line-end conventions.
>>>
>>> Then you did not got burn enough by moving files between OSes
>>> I regularly spent time with tr on unix just to clean such kind of things.
>>>
>
> Hi Igor
>
>>
>> Trust me, i burnt to the point that i don't want to see or hear about
>> them again in my life. And Juan's editor displaying 'lf' glyphs is
>> like 'wellcome back, to hell'.
>>
>
> Just what [] box are currently :) but a bit more informative.
> Don't flame me, I don't support this feature as a reasonnable default.
>
>> Squeak's text editor allows you to do some formatting, like changing
>> font, emphasis, color and more special things like links etc..
>> And once you changing text using this, you can't represent it as
>> plaing text without losing formatting information, and from that point
>> preserving line ends becoming too minor issue comparing to fact that
>> you can't preserve formatting.
>>
>> As to me, from this side, a text editor behaves like html renderer,
>> while displaying control characters is analoguous to displaying html
>> source instead of rendering it. Now tell me, have you seen html
>> renderer , which instead of rendering page - showing you tags?
>>
>
> +1
> So I'm happy to notice you should agree on my modification for
> rendering linefeed transparently in trunk.
>

And i appreciate that.
I just think that conceptually, putting code which handling line feeds
in editor or renderer code is wrong.
Line feeds should be wiped out (converted) before passing to renderer/editor.

>> Or if you prefer to see html source, then it is logical to diplay all
>> other kinds of formatting with plain text (by using some kind of
>> markup), instead of reflecting them visually. No?
>>
>> And then, don't you think that rendering html and displaying html is
>> done using different tools, because obviously it is two different
>> representations of same document. And nobody mixing them (you don't
>> see any tags when browsing, while can see them when looking at
>> source), while Juan's modification looks like a mixture of two
>> different modes - 'raw' mode, when you can see source and rendering
>> mode - when you see the designed document.
>>
>> Such kind of mixture is awfully wrong. So, if you want to see line
>> feeds in text, then get rid of text formatting features first,
>> or make two SEPARATE TOOLS, each specialized on different displaying mode.
>>
>
> Good sense of logic, that's a smart demonstration.
> But we have to be pragmatic too.
> If we limit this feature to poor text editors (character files), the
> demonstration about rich text does not really apply.
> Be it an option or a separate tool does not really matter. Notepad++
> and lot of other string editors have this as an option.
> As long as it is an option in FileList tool and not the main
> behaviour, I think you could tolerate it, couldn't you ?
>

I am fairly looking from pragmatic point: Don't left line ends mess
enter the image.

If you want to see them when browsing files in file list - fine.
I just curious, how useful it is, since there is a plenty of other
tools in OS(es) which allow you do same (browsing file system +
viewing file contents), but in much more convenient manner. Maybe it
hurts someone's feelings, but i think that file list tool is thing
which too far from one which can called usable. It is simple, and lets
you view and open files, but i using it only when i need something to
be loaded into image , and i am always know what file(s) i want to
load before opening file list tool. And i closing file list
immediately after loading necessary files, and never using it to
search for files or browse the file system, simply because i'm not a
masochist.

But lets get back to editor:
i have no idea for what purpose this mess (cr/lf) should get past the
import barriers and appear inside browser or workspace. Anyone wants
to deal with such mess there?
So, here is straightly pragmatic point: leave this mess where it came
from - ouside world.

A plain text is not a bitmap image, which requires a bit-identical
rendering and color matching and as soon as it is readable, there is
nothing else we need.

As a last sidenote: i really like how HTML standard deals with it: it
treats any control characters as a white space - be it space, cr, lf,
tab etc, and using a markup for indicating line breaks or new
paragraphs.
This makes renderer to be completely agnostic from weirdness, which
comes from ancient terminal-based ages.

> cheers
>
> Nicolas
>

--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About end of line convention

hernanmd
Hi guys,
  I think a renderer or editor should be completely unaware about the
underlying format of a file. A renderer could be concerned about text
drawing, glyphs buffering (when appropiate, i.e. non-latin scripts),
display maintenance when scrolling, colouring, etc. An editor should
manage searching data, editing large files, keyboard input, etc.
But...

if computer gurus of the ' 70 invented 6 forms of end-of-line, one per
operating system, and they didn't thought in terms of objects, let's
leave it there. Conceptually end-of-line, line-breaks, form-feeds,
line-separators and other control codes are computer artifacts
necessary to format natural language text. They reveal an intention of
a human to separate blocks of text semantically. But AFAIK there is no
end-of-line grapheme in natural human languages, and so this
inheritance from the ´70 should be as isolated as possible, let's use
an intuitionistic logic in a clever way and everything would become
clear :)

A formatter object, separated from rendering and editing, should end
in a clean implementation. Using a formatter or another is a matter of
the role of the human or the tool working with the file contents (it's
so hard to assume things about humans...), but to me, Smalltalk should
not be married anymore with the historical problems of others.

Cheers,

Hernán

2009/11/20 Igor Stasenko <[hidden email]>:

> 2009/11/20 Nicolas Cellier <[hidden email]>:
>> 2009/11/20 Igor Stasenko <[hidden email]>:
>>> 2009/11/20 Stéphane Ducasse <[hidden email]>:
>>>>>
>>>>> The way how CIUS solves this shown at screenshot.
>>>>>
>>>>> My humble question:
>>>>> if i created a text file, what you think is more important to me:
>>>>>  - being able to clearly read the text
>>>>>  - or being able to see all control characters which may differ from
>>>>> OS to OS???
>>>>
>>>> sorry but you are wrong.
>>>> I saw how this is done in CUIS and if you want to see the end line character
>>>> you can see them, else not.
>>>> I'm often burned with not having that and I think that his solution is cool.
>>>>
>>>>> My line of argumentation is, that text editor should serve for editing
>>>>> a text, but not some sort of binary-mode editing
>>>>> where text is a mix of usual symbols and non-human stuff, which having
>>>>> meaning only to computer.
>>>>
>>>> No
>>>>
>>>>> If i would want to see a binary contents of file, i use hex dump
>>>>> display/edit, but not text editor.
>>>>> (see another attachment)
>>>>
>>>> No
>>>>
>>>>> Use right tool for things you do. By making a single tool for serving
>>>>> everything - as result you getting a horrific & complex monster
>>>>> without any means how to manage it and improve.
>>>>
>>>> No
>>>>
>>>>>
>>>>>> He told me that in the squeak world people were pushing that the end of line is controlled by the platform.
>>>>>
>>>>> This is not correct.
>>>>> I am pushing the idea, that text editor should serve to edit and
>>>>> display text, and don't care about preserving or dealing with
>>>>> different line-end conventions.
>>>>
>>>> Then you did not got burn enough by moving files between OSes
>>>> I regularly spent time with tr on unix just to clean such kind of things.
>>>>
>>
>> Hi Igor
>>
>>>
>>> Trust me, i burnt to the point that i don't want to see or hear about
>>> them again in my life. And Juan's editor displaying 'lf' glyphs is
>>> like 'wellcome back, to hell'.
>>>
>>
>> Just what [] box are currently :) but a bit more informative.
>> Don't flame me, I don't support this feature as a reasonnable default.
>>
>>> Squeak's text editor allows you to do some formatting, like changing
>>> font, emphasis, color and more special things like links etc..
>>> And once you changing text using this, you can't represent it as
>>> plaing text without losing formatting information, and from that point
>>> preserving line ends becoming too minor issue comparing to fact that
>>> you can't preserve formatting.
>>>
>>> As to me, from this side, a text editor behaves like html renderer,
>>> while displaying control characters is analoguous to displaying html
>>> source instead of rendering it. Now tell me, have you seen html
>>> renderer , which instead of rendering page - showing you tags?
>>>
>>
>> +1
>> So I'm happy to notice you should agree on my modification for
>> rendering linefeed transparently in trunk.
>>
>
> And i appreciate that.
> I just think that conceptually, putting code which handling line feeds
> in editor or renderer code is wrong.
> Line feeds should be wiped out (converted) before passing to renderer/editor.
>
>>> Or if you prefer to see html source, then it is logical to diplay all
>>> other kinds of formatting with plain text (by using some kind of
>>> markup), instead of reflecting them visually. No?
>>>
>>> And then, don't you think that rendering html and displaying html is
>>> done using different tools, because obviously it is two different
>>> representations of same document. And nobody mixing them (you don't
>>> see any tags when browsing, while can see them when looking at
>>> source), while Juan's modification looks like a mixture of two
>>> different modes - 'raw' mode, when you can see source and rendering
>>> mode - when you see the designed document.
>>>
>>> Such kind of mixture is awfully wrong. So, if you want to see line
>>> feeds in text, then get rid of text formatting features first,
>>> or make two SEPARATE TOOLS, each specialized on different displaying mode.
>>>
>>
>> Good sense of logic, that's a smart demonstration.
>> But we have to be pragmatic too.
>> If we limit this feature to poor text editors (character files), the
>> demonstration about rich text does not really apply.
>> Be it an option or a separate tool does not really matter. Notepad++
>> and lot of other string editors have this as an option.
>> As long as it is an option in FileList tool and not the main
>> behaviour, I think you could tolerate it, couldn't you ?
>>
>
> I am fairly looking from pragmatic point: Don't left line ends mess
> enter the image.
>
> If you want to see them when browsing files in file list - fine.
> I just curious, how useful it is, since there is a plenty of other
> tools in OS(es) which allow you do same (browsing file system +
> viewing file contents), but in much more convenient manner. Maybe it
> hurts someone's feelings, but i think that file list tool is thing
> which too far from one which can called usable. It is simple, and lets
> you view and open files, but i using it only when i need something to
> be loaded into image , and i am always know what file(s) i want to
> load before opening file list tool. And i closing file list
> immediately after loading necessary files, and never using it to
> search for files or browse the file system, simply because i'm not a
> masochist.
>
> But lets get back to editor:
> i have no idea for what purpose this mess (cr/lf) should get past the
> import barriers and appear inside browser or workspace. Anyone wants
> to deal with such mess there?
> So, here is straightly pragmatic point: leave this mess where it came
> from - ouside world.
>
> A plain text is not a bitmap image, which requires a bit-identical
> rendering and color matching and as soon as it is readable, there is
> nothing else we need.
>
> As a last sidenote: i really like how HTML standard deals with it: it
> treats any control characters as a white space - be it space, cr, lf,
> tab etc, and using a markup for indicating line breaks or new
> paragraphs.
> This makes renderer to be completely agnostic from weirdness, which
> comes from ancient terminal-based ages.
>
>> cheers
>>
>> Nicolas
>>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project