send

send

[Scott Schwartz]

Picture this.  In one buffer you have some text, which is selected as
dot.  In the sam window you have some stuff, including ``|fmt''.  In
the sam window, you sweep out ``|fmt'' and select "send" twice in a
row.  The second time, the command fails, because the output of the
pipe has become the text to send.  Does anyone else find that odd?

Re: send

[Chris Siebenmann]

 I don't think it's particularly odd; it's a consequence of some
decisions about what goes in the cut buffer (I think that if you'll
check you'll find that what you get is the text before the |fmt, not
the pipe's output).

	- cks

Re: send

[John Mackin]

    Picture this.  In one buffer you have some text, which is selected as
    dot.  In the sam window you have some stuff, including ``|fmt''.  In
    the sam window, you sweep out ``|fmt'' and select "send" twice in a
    row.  The second time, the command fails, because the output of the
    pipe has become the text to send.  Does anyone else find that odd?

Chris is right.  No former mux user would ever find this odd :).

The way it works is: "send" sends whatever is in the snarf buffer,
_unless_ there is a non-null selection in the window where you
are doing the "send"ing, in which case it sends the selection
instead.  This is good design: you don't want to have to
go select, "snarf", "send".  So, you select |fmt and then send.
Now this replaces the snarf buffer with what gets cut -- just
as Chris said -- and you will notice that the selection in the
sam window goes away.  This is a necessary consequence of the way
the frame library works; since there's going to be an insertion
in the sam window (that is, the "!" indicating that the command
completed -- preceded by the head of its standard error, if any),
it moves the insertion point (i.e. the selection) to the end and
makes it zero-length.

I can well understand that this might seem a little unnatural to
people whose minds have been polluted by the Horror of X, where
the insertion point and the selection are largely decoupled.
However, this is by far the more natural model, IMHO.  It
certainly works better in practise.  It's _much_ nicer to be
able to edit your windows and then just "send" than it is to
have to piece together a command on the command line the way
you have to with xterm -- and even then you can't go back and
edit it with the mouse before you hit newline, since the
canonicalisation is happening all the way back in the tty
line discipline in the kernel.  This is just horrendous.

Now that we have a freely-distributable frame library, one day
I'll get a better terminal program out to the world.  One day... :)

By the way, I'm currently doing a version of Michael's scrolling
menu that has a fixed upper part, like the jtools version of sam.
If anyone else is doing that, mail me so we can avoid duplicating
the effort.  I'll send it to the list when it's done.

Enough for now.

OK,
John.