Re: [dwm] st terminal

Hi!

This is a very great idea! In this way I can drop nasty screen...

Enno Boland

2007/3/15, Anselm R. Garbe <arg_AT_suckless.org>:
> On Thu, Mar 15, 2007 at 12:05:44PM +0100, Szabolcs Nagy wrote:
> > >2kSLOC and I think the final version will be not above 2.5kSLOC,
> > >dunno why all those other coders need to put a terminal into ten
> > >thousands of lines...
> >
> > maybe i'm blind but st does not handle a lot of things others do (well
> > most of those stuff are unnecessary but still)
> >
> > * many esc sequences from man console_codes are not implemented (eg
> > some standard ECMA-48 codes)
> > * also no selection
> > * no char map changing
> > * no utf-8 decoding and unicode support (and don't forget about the
> > many other encodings)
> > * no scrollback history
> > * no fast scrolling (most terminals does not scrol line by line when
> > it gets lot of input like 'cat src/*.c')
> >
> > if you'd implement these then your code would be much larger
> >
> > implementing a terminal emulator bound to be bloated since the spec is
> > bloated
> > either your code will be huge or it won't be standard compliant
> >
> > of course those 'standards' are mostly deprecated/unneccessary/unused
> > but still i thought i'd point this out that there is a reason why they
> > are so huge
>
> I still doubt the features you mention can't be achieved in some
> 100 lines of code. Actually the UTF8 part is rather simple, st
> will only work with UTF8 correctly (*there is absolutely no
> reason to use anything else nowadays*), scrollback history is
> very simple to achieve, same with fast scrolling, selection has
> been partly implemented by the author of blurt, but is
> unfinished (however the important stuff is already there), there
> are missing escape sequences, which need to be implemented (the
> whole escape sequence handling sucks atm).
>
> And there will be a very deep architectural change, st will
> consist of two programs by default - a daemon which runs in
> background and handles the buffers and tty/pty sessions, and a
> viewer which is an X application and runs in foreground - a
> viewer can be de/attached and using this way one can change
> font/style using a new viewing instance on the same tty easily,
> screen will be made obsolete, because the st daemon will survive
> X server restarts and allow to attach/detach the buffers to
> several different X servers. At least that's what I have in mind
> (note, once I begin to write my editor, it will be compliant to
> be attached/detached using this viewer).
>
> Regards,
> --
> Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361
>
>

-- 
http://www.gnuffy.org - Real Community Distro
http://www.gnuffy.org/index.php/GnuEm - Gnuffy on Ipaq (Codename Peggy)