Re: [wmii] moving liblitz on

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 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.

> > 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.

> 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).

> 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.

> 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.

Regards,

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