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 <[email protected]>: > 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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
