sam-fans - fans of the sam editor
 help / color / mirror / Atom feed
From: John (Deceased persons have no earning capacity) Mackin <john@civil.su. oz.au>
To: Sam Fans <sam-fans@hawkwind.utcs.toronto.edu>
Cc: Solid Hogan <dhog@cs.su.oz.au>
Subject: Re: send
Date: Fri, 4 Dec 1992 02:03:35 -0500	[thread overview]
Message-ID: <199212041803.6362.sam.babin@civil.su.oz.au> (raw)
In-Reply-To: <92Dec3.214153est.2516@groucho.cs.psu.edu>

    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.


      parent reply	other threads:[~1992-12-04  7:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1992-12-04  2:41 send Scott Schwartz
1992-12-04  2:47 ` send Chris Siebenmann
1992-12-04  7:03 ` John Mackin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199212041803.6362.sam.babin@civil.su.oz.au \
    --to=john@civil.su.oz.au \
    --cc=dhog@cs.su.oz.au \
    --cc=sam-fans@hawkwind.utcs.toronto.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).