> Yes, indeed. Both acme and samterm ship with their very own window > manager, so you can fullscreen acme in rio and pretend you're using > wmii. And samterm is even worse: a stacking window manager > within a > stacking window manager (so you can stack while you stack). > > There is a good reason why a curses samterm would be useful: the > standard one is a joke. I have not found any program in which it is > slower to do work. With dwm and vim you can manage development tasks > using nothing but muscle memory. With sam you have to move term, > resize term, move flayer, resize flayer, position cursor, insert some > text, move the cursor horizontally but never vertically... > > But I'd much prefer a sane curses samterm to vim, since (as I > mentioned during one of our many flame wars) I dislike its modality > and its tendency to work completely differently on each machine. And > sam, after all, has lovely things like structural regular expressions.
I'm glad that I'm not the only one who feels this way. I find vi(m) to be totally incomprehensible, though. I find even sam -d to be easier than vi(m). Mostly because the command set in sam is so good. > I have looked into making a curses samterm before, but it's > complicated by the fact that the standard samterm is coded in a > ridiculously cryptic way. Sorry Rob, but what on earth. I'm sure there > must be internal Bell Labs documentation on that thing. I think step > one in writing a new samterm is to work out exactly how the sam > protocol works (I have a fair idea), and to write a new client > implementation from scratch, not just borrowing from samterm/mesg.c. Then the totally new samterm is the way to go. Especially considering that the interface should be totally different (like I mentioned earlier). How different is the protocol from sam -d? I will have to do some reading. Now that I know there is at least one other person interested, I might do some more serious thinking and see what I can code up.
