the obvious. =)

the obvious. =)

[James A. Robinson]

I just have to shout to the world (well, to sam fans) that this editor
is wonderful! Now that I'm actually working directly in sam instead of
just using it via a pipe (from wily), I'm amazed at how much easier it
is to do stuff.

One of the things I tend to do in Java is write a method with name X
that takes no args, X(), or takes N args, X(N). X() tends to just pass
some sort of defaults on to X(N).

When writing JavaDoc comments for each method, it's a major pain
a lot of it tends to be a straight copy and paste one to the
other

Now, with sam, I can just write the top java doc comment, and when
I'm finally ready I can just write

,x/^\/\*(.+\n)+ \*\/\n/ t /}\n/

To copy the top comment down to the second method. e.g.

	/**
	 * 1-5 lines describing Foo
	 */
	public void X()
	{
		...
	}
	public void X(N)
	{
		...
	}

turns into

	/**
	 * 1-5 lines describing Foo
	 */
	public void X()
	{
		...
	}
	/**
	 * 1-5 lines describing Foo
	 */
	public void X(N)
	{
		...
	}

sam's slogan ought to be 'Making your life easier through
structured regular expressions.' =)

Jim

Re: the obvious. =)

[rob pike]

	,x/^\/\*(.+\n)+ \*\/\n/ t /}\n/

Regular expressions have their limitations, which is why Sam
also has addresses. These provide a simpler and safer way to
match multi-line things like comments:

	,x/^\/\*/ .,/\*\/\n/ t /}\n/

This one works even if there are no blank lines.
Here's a troff paragraph-at-a-time pattern:

	,x/^\.PP/ .,/^\.(PP|SH)/-     ...

Also if there's a slash in the pattern, you can use another character
as the delimiter and save a backslash, as in this example for C++ //
comments:

	x/\/\//  goes to x;//;

Have fun.

-rob

Re: the obvious. =)

[James A. Robinson]

> # Do these guys: &, <, > :
> [,x/&|<|>/{
>  g/&/c/&amp;/
>  g/</c/&lt;/
>  g/>/c/&gt;/
> }]
> 
> where double clicking inside the last [bracket] backhilites this
> section (but not the [ ] brackets), snarf it, click in the text
> file, sam it, and send it. Bang, end of story.

That's a pretty good idea. Coming off of using wily (an Acme clone),
one of the things I thought about doing was writing a set of guide
files for sam.  It's really too bad one can't have a real acme clone
(with the same neat file handling) with a sam command window! =)

> # BOLD FACE DOT:
> [s/./<b>&/
>  a/<\/b>/ ]

Since you have dot selected, why not just [s/.+/<b>&<\/b>/]?

> If you're at the EOF when you dot-out of text entry, it's easy to
> get back; otherwise one can type e.g. zz, then dot out, make the
> correction, and get right back to zz and continue on.

Is there any vi influance here (zz)? =)  I'm wondering if you really
enter most of your text via the command window? I'd find it hard to go
back and hunt down previous commands from the scroll-back.

Does anyone have a nice make system in place to use from sam, or perhaps
etags support?  I'm thinking of writing up a make script that will
dump the results to an ERRORS file and open it up using sam's pipe.
If it exists one could send 'e ERRORS' and stuff as well, I suppose.


Jim

P.S.
In case folks are interested, here is a diff of changes I had
to make against sam.1 in order to read the man page on my Linux
box (the original works fine under Solaris, but linux's groff
barfs on it).

*** sam.1.orig	Wed Mar 22 12:36:06 2000
--- sam.1	Wed Mar 22 12:39:24 2000
***************
*** 20,26 ****
  .de TF
  .br
  .IP "" \w'\fB\\$1\ \ \fP'u
! .PD0
  ..
  .de EX
  .CW
--- 20,26 ----
  .de TF
  .br
  .IP "" \w'\fB\\$1\ \ \fP'u
! .PD
  ..
  .de EX
  .CW
***************
*** 71,77 ****
  the editor's file until it first becomes the current file\(emthat to
  which editing commands apply\(emwhereupon its menu entry is printed.
  The options are
! .TF "\-r machine  "
  .TP
  .B \-d
  Do not download the terminal part of
--- 71,77 ----
  the editor's file until it first becomes the current file\(emthat to
  which editing commands apply\(emwhereupon its menu entry is printed.
  The options are
! .TF
  .TP
  .B \-d
  Do not download the terminal part of
***************
*** 105,111 ****
  to represent newlines.
  A regular expression may never contain a literal newline character.
  The elements of regular expressions are:
! .TF "[^abc]   "
  .TP
  .B .
  Match any character except newline.
--- 105,111 ----
  to represent newlines.
  A regular expression may never contain a literal newline character.
  The elements of regular expressions are:
! .TF
  .TP
  .B .
  Match any character except newline.
***************
*** 145,151 ****
  and
  .I r2
  are regular expressions.
! .TF "r1|r2   "
  .TP
  .BI ( r1 )
  Match what
--- 145,151 ----
  and
  .I r2
  are regular expressions.
! .TF
  .TP
  .BI ( r1 )
  Match what
***************
*** 210,216 ****
  All files always have a current substring, called dot,
  that is the default address.
  .SS Simple Addresses
! .TF ?regexp?
  .TP
  .BI # n
  The empty string after character
--- 210,216 ----
  All files always have a current substring, called dot,
  that is the default address.
  .SS Simple Addresses
! .TF
  .TP
  .BI # n
  The empty string after character
***************
*** 223,229 ****
  .IR n .
  .TP
  .BI  / regexp /
! .PD0
  .TP
  .BI ? regexp ?
  The substring that matches the regular expression,
--- 223,229 ----
  .IR n .
  .TP
  .BI  / regexp /
! .PD
  .TP
  .BI ? regexp ?
  The substring that matches the regular expression,
***************
*** 272,278 ****
  and
  .I a2
  are addresses.
! .TF "a1+a2   "
  .TP
  .IB a1 + a2
  The address
--- 272,278 ----
  and
  .I a2
  are addresses.
! .TF
  .TP
  .IB a1 + a2
  The address
***************
*** 413,419 ****
  .br
  .ne 1.2i
  .SS Text commands
! .PD0
  .TP
  .BI a/ text /
  .TP
--- 413,419 ----
  .br
  .ne 1.2i
  .SS Text commands
! .PD
  .TP
  .BI a/ text /
  .TP
***************
*** 526,532 ****
  Print a menu of files.
  The format is:
  .RS
! .TF "XorXblankXX"
  .TP
  .BR ' " or blank"
  indicating the file is modified or clean,
--- 526,532 ----
  Print a menu of files.
  The format is:
  .RS
! .TF
  .TP
  .BR ' " or blank"
  indicating the file is modified or clean,
***************
*** 791,797 ****
  provides the following operators, each of which uses one or
  more cursors to prompt for selection of a window or sweeping
  of a rectangle.
! .TF "reshape "
  .TP 
  .B new
  Create a new, empty file:
--- 791,797 ----
  provides the following operators, each of which uses one or
  more cursors to prompt for selection of a window or sweeping
  of a rectangle.
! .TF
  .TP 
  .B new
  Create a new, empty file:
***************
*** 873,879 ****
  quoted strings or bracketed strings, depending on the text at the click.
  .PP
  Button 2 provides a menu of editing commands:
! .TF "/regexp"
  .TP
  .B cut
  Delete dot and save the deleted text in the snarf buffer.
--- 873,879 ----
  quoted strings or bracketed strings, depending on the text at the click.
  .PP
  Button 2 provides a menu of editing commands:
! .TF
  .TP
  .B cut
  Delete dot and save the deleted text in the snarf buffer.

Re: the obvious. =)

[kim kubik]

-----Original Message-----
From: James A. Robinson <jim.robinson@stanford.edu>
To: kim kubik <chaotrope@jps.net>
Cc: sam Fans <sam-fans@hawkwind.utcs.toronto.edu>
Date: Saturday, March 25, 2000 5:54 PM
Subject: Re: the obvious. =)


>> >,x/^\/\*(.+\n)+ \*\/\n/ t /}\n/
>>
>> this just ran up against my (mis)understanding of
>> sam's regexp's. >
>
>Here's what I *think* is going on, but I'm no regex guru...  A
'(.*\n)+'
>would keep it going to the end of the file. With '(.+\n)+' I'm
specifying
>that there must be at least one character before the newline. So this
>match ends at the first blank line.  I think the engine then backtracks
>until it finds a match for ' \*\/'

Jim -

I tried a couple of different scenarios on before I posted
and *think* a blank line was one of the first I tried since
the . in (.+\n)+ obviously needs to match something "real".
Since I can't remember exactly, my best guess is that what I
tried must have been something like:

/**
 * stuff about foo
 *
 * and the above is a "blank" line
 * only if you're a total moron. . .
 */

which should put me in the forefront of those nominated for
the Homer Simpson Award, Year 2000 ("Doooh!").

Since you seem to like to pass around neat SREs, there are
times when it's necessary to convert a txt file to html and
using a sam "macro" file that I stick off to the side next
to the txt file (and using # faux-comments to remind me what
each does), there are things in txt2htm.sam like:

# Do these guys: &, <, > :
[,x/&|<|>/{
 g/&/c/&amp;/
 g/</c/&lt;/
 g/>/c/&gt;/
}]

where double clicking inside the last [bracket] backhilites this
section (but not the [ ] brackets), snarf it, click in the text
file, sam it, and send it. Bang, end of story.

And when casually perusing the text, if I note something worth
<b>embolding</b>, backhiliting the text of interest and snarfing
this from the "macro" file, sam-ing the text file and sending:

# BOLD FACE DOT:
[s/./<b>&/
 a/<\/b>/ ]

does just that.

And tho old habits are difficult to break, I've learned (but
still find myself forgetting) that one does not need the samX
cursor-arrow keys if you just STAY IN THE SAM COMMAND WINDOW
and move around using /re and -/re.  It is so much easier than
cursoring around, trying to remember which <ctrl>-Duh moves right
one word, whatever.  You're looking at 'miscake' and want it to be
'mistake' and almost as if sam can read one's mind, you just
dot-out and send the cursor there in one move, make the correction,
and get back where you were.

If you're at the EOF when you dot-out of text entry, it's easy to
get back; otherwise one can type e.g. zz, then dot out, make the
correction, and get right back to zz and continue on.

Maybe all this is obvious to everyone but me. . . most things are.

 - kim

Re: the obvious. =)

[James A. Robinson]

> >,x/^\/\*(.+\n)+ \*\/\n/ t /}\n/
>
> this just ran up against my (mis)understanding of 
> sam's regexp's. I'm sure when first using sam I did
> something similar to your example above and the
> 'greedy' little bastard (.+\n)+ would (to my way
> of thinking) eat the whole file, that is, never see
> the closing */ of the commment because the .+ should
> just keep on going.


Here's what I *think* is going on, but I'm no regex guru...  A '(.*\n)+'
would keep it going to the end of the file. With '(.+\n)+' I'm specifying
that there must be at least one character before the newline. So this
match ends at the first blank line.  I think the engine then backtracks
until it finds a match for ' \*\/' -- which is the end of the comment. I
believe the previous match of a newline ensures that it will not hit the
comments within the blocks (as those are '\n\t *').

And yes, I do space indent my comments so the '*' lines up with the
topmost one.  I thought that was in my post, though I did tab-indent
the whole block. Perhaps my mailer munged it.


Jim

Re: the obvious. =)

[kim kubik]

-----Original Message-----
From: James A. Robinson <jim.robinson@stanford.edu>
To: sam Fans <sam-fans@hawkwind.utcs.toronto.edu>
Date: Friday, March 24, 2000 10:26 PM
Subject: the obvious. =)


>I just have to shout to the world (well, to sam fans) that this editor
>is wonderful>I'm finally ready I can just write
>
>,x/^\/\*(.+\n)+ \*\/\n/ t /}\n/
>
>To copy the top comment down to the second method. e.g.
>

Jim (or anyone): 

this just ran up against my (mis)understanding of 
sam's regexp's. I'm sure when first using sam I did
something similar to your example above and the
'greedy' little bastard (.+\n)+ would (to my way
of thinking) eat the whole file, that is, never see
the closing */ of the commment because the .+ should
just keep on going.

But I tried what you have and it works, so obviously
all this time the way I've been getting around this,
using addresses, e.g.

,x/re/{
.,/re2/do stuff
}

isn't necessary.

So what am I missing?

- kim

PS: in your example there's a space after the 
    second + that shouldn't be there, right?
    At least by your example, but probably you
    do comments as:

/*
 * so there really is a space
 * before the last splat.
 *
 */

And the example left this out.