Re: [wmii] moving liblitz on

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