Re: [9fans] sam hacking - a couple of fixes that may apply t

Re: [9fans] sam hacking - a couple of fixes that may apply t

[Richard C Bilson]

> From: steve.simon@snellwilcox.com
>
> If however, the history in the sam window is just text then one is
> quite within ones rights to 'change history', edit it, double click
> to the right of it (to select it) and hit send.

But by double-clicking to the right of the text you pick up the entire
line, plus terminating new-line, right?  So you're not relying on the
add-a-newline behavior.

- Richard

[...who doesn't use sam all that often, but often uses win in the
manner that you describe]

Re: [9fans] sam hacking - a couple of fixes that may apply t

[boyd, rounin]

> But by double-clicking to the right of the text you pick up the entire
> line, plus terminating new-line, right?

you're assuming the command fits on one line.

some of the stuff i construct in the command window is multi line,
hence send is really useful.  it is also consistant with the window
manager.

i don't like acme.  it has some interesting ideas, but i can't use it.

rob wrote in one of the sam papers (iirc) that most people don't use
complex sam commands.  i used to be like that, until i learnt the error
of my ways, so now i construct fairly complex stuff and refine it till
it's right.

having 'perfect' undo means i can make a wild guess, try it, undo it
if it's wrong, and loop until i have something that smashes multiple
files into the shape i want them.

Re: [9fans] sam hacking - a couple of fixes that may apply t

[Douglas A. Gwyn]

boyd, rounin wrote:
> rob wrote in one of the sam papers (iirc) that most people don't use
> complex sam commands.  i used to be like that, until i learnt the error
> of my ways, so now i construct fairly complex stuff and refine it till
> it's right.

In BRL's MUVES project, one of our Makefile targets was a
profiled source listing, i.e. execution counts (for a test
run) alongside each source line.  Since there was no tool
on our Unix systems that did that, I cobbled one up as a
combination of existing tools and a "sam" script that was
several hundred characters long.  Worked fine!

I have a file of "macors" for sam; I open that file as one
file within "sam", then snarf and send to execute when
needed.

Re: [9fans] sam hacking - a couple of fixes that may apply t

[boyd, rounin]

> I have a file of "macors" for sam; I open that file as one
> file within "sam", then snarf and send to execute when
> needed.

i have a thing called 'samit', which B's itself, and contains useful stuff.

from the command window i:

    !samit
    <right click>

Re: [9fans] sam hacking - a couple of fixes that may apply t

[Derek Fawcus]

On Fri, Jul 04, 2003 at 12:08:01PM +0200, boyd, rounin wrote:
> i have a thing called 'samit', which B's itself, and contains useful stuff.

Speaking of B,  one other thing I noticed wrt to the unix (X11) version
is that the pipe for B is exported by samterm not sam.  This means that
if they are running on seperate machines,  B is not so convenient to
use - i.e. it can't be used as say "B *.h' and do what you'd like.

DF

Re: [9fans] sam hacking - a couple of fixes that may apply t

[Douglas A. Gwyn]

Derek Fawcus wrote:
> Speaking of B,  one other thing I noticed wrt to the unix (X11) version
> is that the pipe for B is exported by samterm not sam.  This means that
> if they are running on seperate machines,  B is not so convenient to
> use - i.e. it can't be used as say "B *.h' and do what you'd like.

Then somebody must have broken that version.  The one I maintain
(at one time widely used in BRL) has multiple vrsions of samterm,
most of which run as processes within the terminal (5620, 630).
There is no Unix in those terminals, yet the pipe feature works,
operating in the host environment (which is where the files live).
They also work with sam -r, which runs the host part on a remote
host.  (We used to edit files on the Cray mainframes this way.)

Re: [9fans] sam hacking - a couple of fixes that may apply t

[steve.simon]

[-- Attachment #1: Type: text/plain, Size: 777 bytes --]

Hi,

As one of (I suspect) a dieing breed of intensive sam users
I like send appending \n.

I believe it's a matter of outlook. If you regard sam's command window
as a typescript then you tend to assemble a command at the
output/input point which requires many laborious cut and pastes.

I can imagine not having to move the mouse before doing the paste would
then seem very attrictive.

If however, the history in the sam window is just text then one is
quite within ones rights to 'change history', edit it, double click
to the right of it (to select it) and hit send.

I do this dozens of times a day.

just my 2¢ worth ;-)

-Steve

PS. thanks Rob for releasing it alll those years ago, it has been
a pool of sanity in an ever changing OS enviroment.

[-- Attachment #2: Type: message/rfc822, Size: 725 bytes --]

From: 9fans@cse.psu.edu
To: 9fans@cse.psu.edu
Subject: Re: [9fans] sam hacking - a couple of fixes that may apply t
Date: Thu, 03 Jul 2003 17:43:01 +0100
Message-ID: <2149465875@snellwilcox.com>

> does anyone actually find it useful with the newline

it was done this way for consistency with 'send' in the old blit window manager.
isolated in an editor, it makes much less sense.

-rob

Re: [9fans] sam hacking - a couple of fixes that may apply t

[Derek Fawcus]

On Thu, Jul 03, 2003 at 06:06:04PM +0100, steve.simon@snellwilcox.com wrote:
> Hi,
>
> As one of (I suspect) a dieing breed of intensive sam users
> I like send appending \n.
>
> I believe it's a matter of outlook. If you regard sam's command window
> as a typescript then you tend to assemble a command at the
> output/input point which requires many laborious cut and pastes.
>
> I can imagine not having to move the mouse before doing the paste would
> then seem very attrictive.
>
> If however, the history in the sam window is just text then one is
> quite within ones rights to 'change history', edit it, double click
> to the right of it (to select it) and hit send.
>
> I do this dozens of times a day.

Hmm - I get it.  Please take into account this is my first serious
attempt to use the editor (and the UI) since I forst read the paper
in '87.

I see how you're using it,  and I agree it's behaviour makes sense
in that context.  What I was using it for was pasting dot from an
editor window into the command window - without trashing the snarf
buffer.

In a similar vein,  what sort of things do people use the ESC key
behaviour for?  I'd guess it's intended for use with 'look' but has
the side effect of chucking extra text into the editor window.  Or
is one expected to play games bouncing back to the sam window,  undo,
then some search (either regex in sam window,  or look back in editor
window).

Anyway,  I guess I should have a bit more of a play before I hack too
much :-)

The other hack I'm playing around with is the arrow keys - I keep on
hitting them and getting confused.  So I've made left/right dead keys,
and (if I can figure it easily) will make up/down scroll one line,
else they'll become dead keys as well.

DF