Re: [dev] curses samterm

On 8/3/2010 11:14 AM, Connor Lane Smith wrote:
> Hey,
>
> On 3 August 2010 09:50, Joseph Xu<josephzxu_AT_gmail.com> wrote:
>> Very few people use sam to begin with, even fewer would like the curses
>> interface. I'm guessing no more than 20 people.
>
> The best reason not to write a program ever: nobody is using it yet.

I said I'm guessing no more than 20 people will find it useful if it was
written.

>
>> Usually I'll have acme always running and just plumb stuff to it. Actually
>> you can almost live inside acme like you can live inside emacs.
>
> 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...

I agree the sam internal window manager is kind of ridiculous. Pike must
have thought so too, since he made acme very differently. The inability
to move the cursor up and down lines is weird too, I think that has to
do with the fact that internally both sam and acme represent buffers as
streams of characters rather than lines. At least that's my understanding.

>
> 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.
>
> (But let's not have another flame war.)
>
> 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.
>
> Thanks,
> cls
>
Received on Tue Aug 03 2010 - 18:43:17 CEST