2009/11/20 Nicolas Cellier <[email protected]>: > 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. >
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 [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
