2009/11/20 Igor Stasenko <[email protected]>: > 2009/11/20 Stéphane Ducasse <[email protected]>: >>> >>> 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 >>>> [email protected] >>>> 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 >>> [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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > 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
