Re: [wmii] moving liblitz on

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" <garbeam_AT_wmii.de> 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" <garbeam_AT_wmii.de> 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
> >
> > _______________________________________________
> > wmii_AT_wmii.de mailing list
> > http://wmii.de/cgi-bin/mailman/listinfo/wmii

> _______________________________________________
> wmii_AT_wmii.de mailing list
> http://wmii.de/cgi-bin/mailman/listinfo/wmii

-- 
 Anselm R. Garbe  ><><  www.ebrag.de  ><><  GPG key: 0D73F361