[9fans] sam & rio

[9fans] sam & rio

[baldwin]

rob mentions the danger of having two interfaces being almost the same
but different as an argument against having DEL act differently in sam
and rio.

i'll just mention my major point of frustration on this topic: the
lack of chorded cut/paste in sam.  i am so used to do this in rio and
acme that i have become almost crippled in sam.  the lack of
auto-scroll° and selecting off the top or bottom of the window round
out my list of annoying diffs between sam and rio/acme.

luckily, with the addition of the sam command language to acme, i now
have no reason to use sam†.  now if acme only did "win" windows as well
as rio (how i miss the input/output point distinction), i might not
run rio either‡.

° why doesn't auto-scroll work with the middle and right buttons?
† splitting front-end from back-end is still useful for slow links.
‡ of course, graphing programs must still be run from rio.

Re: [9fans] sam & rio

[rob pike]

I regret that sam doesn't do chorded cut and paste, and have tried
several times to fix that deficiency, but the split design of sam
causes a division of labor that makes chording very difficult.  The
same applies to scrolling when selecting.

On the other hand, I find the monolithic design of acme limits its
ability to do some other things, such as work well over slow links.

If win worked as a file system serving /dev/cons itself, it would
behave a little better, but there would still be a race between where
acme puts stuff and where win thinks it is.  That is fixable by
extending acme's external interface somewhat, but at that point you've
built three levels of file system serving /dev/cons and it seems like
overkill to me.  My solution is not to run win much, either.  I always
thought of it as an expedient workaround.  Acme iself is already a
shell.

-rob