> 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.
Received on Tue Aug 03 2010 - 20:10:43 CEST
This archive was generated by hypermail 2.2.0 : Tue Aug 03 2010 - 20:12:02 CEST