Hi, first, thanks for your reply
I think you didn't get all of my ideas. I know both ncurses and screen and for me they are signs that the basic concept (layers upon layers) is flawed. I think I'm too young to say I remember DOS well, but I've been playing with toy kernels and writing directly into memory under 0xb8000. I even wrote some kind of a very dumb terminal emulator.
So, look, for example. If such "splitted terminal" would be the primary interface provided by Linux right after boot, in the text mode, we could ask the user for login credentials while the rest of the system is booting (like starting XDM before any other services, but come on, XDM (and other DMs) sucks). This of course would need lots of changes in the kernel, and then probably a new
> It's the command interpretor shell that does IO with the terminal,
> and it doesn't have to be re-written: It can be wrapped in another
> layer and/or extended to add even more features.
Nyet, I don't think so. In my opinion, it breaks the "one tool for one job" rule of Unix, and features should be *removed* from it. So it provides a language for scripting and for command execution, AND provides completion, editing, etc. Ever tried to switch to a less-mainstream shell, like Plan9's rc? rc as a language is superior to sh in almost every aspect (save for backwards compatibility), but its line-editing, history and completion capabilities are severally lacking. But let's say you move all of that functionality to the terminal's input widget. The widget would just look at the grammar of the shell (you still need to tell HOW to complete stuff...) and that's it. If somebody is willing to spend some time hacking a completer for it, you could even run Perl as your login shell, with zero changes to the executable.
> Well... Get to Coding!
I will, not kidding.
I like the suckless.org philosophy. They create lots of very small, neat, high quality software, while taking care to keep the design simple and the source code understandable. Never thought I'd be running a window manager with my own patches, but here I am with dwm (http://dwm.suckless.org/). Oh, and they have a terminal emulator in under 2000SLOC of C (http://st.suckless.org/). I guess the "rip out the VT100 emulation and see where can we go from there" part is one boring evening away (not tonight - we're gonna drink vodka).
> However, if you did start out on such a project (as I did)
> you would realize why there are so many messed up layers --
> it's for backwards / forwards / cross-terminal compatibility.
One nice thing is that every well-written program should already support this kind of terminal. If it knows what TERM=dumb means, and if it uses standard isatty(3), there's nothing more to be done to get it working. Actually I just ran "aptitude update|cat" to see if it behaves properly when it can't assume it's OK to update something it already printed, and it ran just fine. Even "aptitude dist-upgrade|cat" behaved like a good citizen when it had to ask questions interactively.
Moreover, Unix seems to be a very flexible toy. You'd think that using svscan (http://cr.yp.to/daemontools/svscan.html) as a drop-in init replacement shouldn't work, right? Well, there's a guy that just hacked some additional initialization&shutdown scripts and it seems to work (http://code.dogmap.org/svscan-1/). Regarding terminal-oriented programs, I recently wrote a simple script that would use Google to translate its stdin into another language. Then wrote a simple GTK program with three buffers, one to type in a command, one which's contents are sent to command's stdin, and one holding the output. The two were designed to work with each other, but just for the kicks I've started all kinds of weird combinations. Piping "ls" to "sh" gave the expected results, similarly piping "print 2+2" to "python". Obviously running curses-based programs caused trouble. But that small hack is only a few steps away from my "next-gen" terminal, and it shows that it will most probably just work.