ACK. On Fri, May 26, 2006 at 01:28:48PM +0200, Denis Grelich wrote: > On Fri, 26 May 2006 09:42:54 +0200 > "Anselm R. Garbe" <[EMAIL PROTECTED]> wrote: > > > On Thu, May 25, 2006 at 03:22:05PM +0200, Denis Grelich wrote: > > > On Thu, 25 May 2006 11:16:45 +0200 > > > "Anselm R. Garbe" <[EMAIL PROTECTED]> wrote: > > > Yes, control characters are not for syntax highlighting. They are > > > for (pre-)defining highlighting. One could send the output of > > > shells that send ANSI-formatted text through a filter that > > > translates it into the widgets formatting language, for example. > > > > Yes, there is no other way without cluttering the > > implementation. Though I won't do this right now. > > It would be no big deal to add later, I suppose. > > > > > It is done dynamically. I don't think it makes much sense > > > > (except for bar label titles maybe) to interpret style markups > > > > in text files. In most cases a colorization should be done > > > > dynamically. I never expected in the past discussion files which > > > > contain extra meta-info beside text. > > > > > > Okay, maybe that is not needed at all and should be made completely > > > dynamic. One could still use filters that write directly to the > > > widget's style metadata structure if one needs predefined colours > > > and styling. > > > > Don't do this for now. If one really needs to add color support, > > one can add it later very easy, as long as the data structure is > > designed with such extension in mind. > > Okay. > > > > > With richtext you need to arrange your layout in sane ways, > > > > that's the hard job. That's why I always told not bothering with > > > > such stuff. A fixed-font widget suffices. > > > > > > That also depends on how much richtext we allow. If we only allow as > > > about much richtext as terminal emulators do, we don't need to > > > rearrange too much to cope with that, I suppose. > > > > Ahm, terminal emulators don't allow richtext at all. Richtext > > means that you can use arbitrary fonts for each letter, > > arbitrary alignments for each line, arbitrary space between > > characters and lines, several z layers of text etc. Richtext is > > a mess. I won't call different colors for different characters > > richtext as long as the same font is used. TeX and troff are the > > only systems which did it _right_ all the time. They are based > > on the fact, that it is not simple to edit and present > > print-quality documents on the screen at the same time in one > > place. That is also why they are rock solid in contrast to > > flaky memory consumers like OO or MS Office. > > Hm, yes. Implementing high-quality richtext typography is indeed not > trivial, and has nothing to do with the planned widget. > > > > I thought terminals should die a bloody and painful death? That's at > > > least what they should do in my opinion. They are too restricted and > > > primitive in my eyes, and they make any sane text handling a mess. > > > (How many terminal emulators do you know that, for example, break > > > text correctly on resize?) > > > > I can't agree. If you mean a terminal sucks, because it still > > depends on the TTY wire protocol or ANSI sucks, I can understand this. > > > > But the basic terminal concept like a line editor is not wrong > > in my eyes. There is no faster way to use the pipe-filter model > > than at the command line. Having a graphical shell, where you > > click onto symbols and connect filter-nodes to design a pipe, > > seems complex and inefficient to me (although this might be a > > good idea for normal users). > > > > The 9term way does not scale in the world of ANSI-driven apps we > > use, that's also the reason why I don't use 9term. That's also > > the reason why I want a term which supports those apps, but > > sucks less as the existing one (which means something like an > > improved 9term). > > Okay, if we talk about the command line interface, I have to agree. > There are situations where a command line interface or a derivation of > it beats any gui, and there surely should be some sane »terminal« (not > teletype emulator!) for this kind of task. Not for gui apps like mutt or > vim. That's a cruel mutilation of the concept. > Therefore I don't think a character-based interface is not necessary at > all. A line based, sure, but no need to be able to access single > characters. > > > > If we made ordering and line breaking and stuff also a filter's > > > job, it would be absolutely no problem to implement a locale and > > > language sensitive strcmp some day. > > > > If the 'filter' is a library call I'm fine with this. > > Yes, that's what I had in mind. > > > > Uhm, strncmp doesn't work either. Don't use that. Also, don't forget > > > that two strings that are /not/ byte-to-byte identical still could > > > need to compare identical in Unicode; C's string functions work > > > only on that assumption! It's not that simple. > > > > strncmp works stable for me. I know there are different Unicode > > encodings for the same glyph, but I don't care. If that is > > possible, Unicode is broken, not our app. > > I would rather use some other library instead C's string library, and > we use only this to manipulate strings. If we used u_strncmp it would > be pretty simple to make it just a call to strncmp for now and extend > it later to something language-, locale- and Unicode-aware. > > > Regards, > > -- > > Anselm R. Garbe ><>< www.ebrag.de ><>< GPG key: 0D73F361 > > > > _______________________________________________ > > [email protected] mailing list > > http://wmii.de/cgi-bin/mailman/listinfo/wmii
> _______________________________________________ > [email protected] mailing list > http://wmii.de/cgi-bin/mailman/listinfo/wmii -- Anselm R. Garbe ><>< www.ebrag.de ><>< GPG key: 0D73F361 _______________________________________________ [email protected] mailing list http://wmii.de/cgi-bin/mailman/listinfo/wmii
