Re: 'sam' available from research.att.com!

Re: 'sam' available from research.att.com!

[Byron Rakitzis]

>For the interested, I have a small set of modifications[...]

I have also hacked sam in a couple of ways:

1) I make command window appear on the left by default. i.e.,
the window is tall&thin, not short&fat. Since most commands
are only a couple of letters long (/foo, x/foo/c/bar, etc.)
it means that you can have a lot more history visible in the
editor than with the short&fat command window. The occasional
long line doesn't bother me.

2) I hacked the selection-positioning code so that that
when the current selection is skipped to, that selection
is in the middle of the screen rather than right at the top.
This makes it a lot easier to take in the context of the
thing you just skipped to. (I dunno, maybe I'm used to it
because vi does it that way.)

3) I fixed an array indexing error in main which causes sam
to dump core when you give it a bad option. (sigh) In general,
I have found that sam likes to dump core all too frequently
under SunOS. Some of the dumps seem to be related to synchronization
problems between sam & samterm: as soon as one goes out of
whack it panics & dumps core.

All these fixes are 1 line fixes, btw, which is nice. Modifying
sam to use, for example, ctags, might be more of a challenge.

Re: 'sam' available from research.att.com!

[Chris Siebenmann]

 Note that the people at Bell Labs who are doing have been silently
updating the sam distribution; unless you've sent them bug reports,
you may not have heard about the new versions. The bug in options
processing that Byron found has been fixed, for example (along with
a bunch of others).

	- cks

Byron's comments

[John Mackin]

    1) I make command window appear on the left by default. i.e.,
    the window is tall&thin, not short&fat.

Use the Scrollbar, Luke!! :)

    2) I hacked the selection-positioning code so that that
    when the current selection is skipped to, that selection
    is in the middle of the screen rather than right at the top.

This is a damn fine plan.  I don't know why I didn't ever do this.
Does this have a good side-effect on what happens when you type at
the bottom of the window?  That is, does it make it scroll only half
instead of the whole window, leaving you with only a line or so of context?
I find that annoying, and so over the years have developed the habit of
never typing across the bottom, but just scrolling with the scrollbar when
that time gets near.  ... hmm.  I have just realised a possible reason
for not doing this.  If you are doing repeated searches for something
that's reasonably frequent (and that's a common idiom of mine: "look"
"look" "look" clicking on Button Two) this could cause twice as many
scrolls.  Hmm.

    In general, I have found that sam likes to dump core all too
    frequently under SunOS.

Yes.  That's the other reason I haven't changed to that version of sam
from the one I am using: it doesn't seem to be solid at all yet.  I have
had a couple of "panic: Bflush"es out of it just in testing.  This is
not a UNIX-version problem; people I know who use Plan 9 say that the
sam on there does this too.  It's not repeatable (read: we don't know
how to repeat it).  The sam I use _never_ panics.

Another reason I haven't switched (as mentioned in mail to Chris earlier)
is that the interface has moved a bit far for my taste from the precisely
Blit-like interface I am now using.  By far the worst aspect is the fact that
the Button Three menu doesn't scroll, but just grows taller without bound
as you add files.

Another reason I haven't switched is because my window manager (gwm 1.7i)
has a bug that prevents clients that use the WM_TAKE_FOCUS protocol, which
the new sam does, from ever getting the focus.  I think David Hogan has a
fix for this -- I haven't gotten it from him yet.  Note that the current
version of gwm (1.7n, I think) exhibits the same symptom for what seems to be
a different reason, and we don't have a fix for that version.

To contrast with the bashing, I was pleased by the performance of the
new sam under test (speed-wise, I mean).  I was concerned since the
libXg they distribute is built on Xt.  The jerq-tools emulation in the
sam I use is built on raw Xlib and is a speed demon.  I was very happy
to see that the new version didn't seem to be noticeably slower.

    Modifying sam to use, for example, ctags, might be more of a
    challenge.

Before anyone tries this, let me say that it would be far, far better
to see if we can get the Labs to give us "samuel" instead.  samuel is sam
with built-in C browser knowledge; much more powerful than ctags.
Caveat: I've never used samuel.  I have, however, spent a bit of time
watching someone who was skilled with it and used to it use it, and it
looked very smooth indeed.  Unfortunately the manual entry isn't in
the printed V10 manual -- they relegated it to section A, the `unprinted
appendix' -- but you get the idea.  Just like sam -- if you don't use the
browser features, you don't notice them -- and the menus remain uncluttered.
But if you want to, you can do all the good things: show me the declaration
of the selected identifier, or all uses of it, etc. etc.

The database handling is particularly nice since it is updated lazily --
and you can go on editing while that's happening.

OK,
John.

Re: 'sam' available from research.att.com!

[Christopher JS Vance]

In article <9211181720.AA16722@penfold.cc.gatech.edu> arnold@cc.gatech.edu (Arnold Robbins) writes:
| me:
| >> change all the \f(I to \fI
| 
| rsalz:
| > and all \f(B to \fB, too.
| 
| I didn't stumble on this; I got rid of the CW macro at the front which
| may be the only place that uses \f(B, but I left the WC macro alone, since
| I don't think groff has the CS font. (Courier Slanted?)
| 
| The joys of troff.

Or you can print the Postcript version in dist/plan9man/*sam*.  (The
plan9man directory was available before sam was.)

-- Christopher

Re: 'sam' available from research.att.com!

[Chris Siebenmann]

 For the interested, I have a small set of modifications to the X
portion of sam that create what I feel are some improvements in
the interface and make it more Blit-like. Send me email if you
want context diffs.

	- cks

Re: 'sam' available from research.att.com!

[Arnold Robbins]

me:
>> change all the \f(I to \fI

rsalz:
> and all \f(B to \fB, too.

I didn't stumble on this; I got rid of the CW macro at the front which
may be the only place that uses \f(B, but I left the WC macro alone, since
I don't think groff has the CS font. (Courier Slanted?)

The joys of troff.

Arnold

Re: 'sam' available from research.att.com!

[rsalz]

>change all the \f(I to \fI
and all \f(B to \fB, too.

'sam' available from research.att.com!

[Arnold Robbins]

I saw an off hand reference in comp.unix.bsd, and sure enough, Rob Pike's
'sam' editor is now up for ftp on research.att.com, in /dist/sam. All
you really need is bundle.Z, a compress shell archive; the README is also
in it.  I had to make some minor changes to sam.tut.ms to get it to
gnu troff; change all the \f(I to \fI.  There's about 4 places.

This is an X11 version ported from Plan 9 back to Unix.  This will probably
motivate me to switch from MGR to X.

So, I thought I'd let all you minimalist junkies on the rc list know
about it.

Arnold