[net.lang.lisp] awk/ vi for Lisp

michaelm@bcsaic.UUCP (michael b maxwell) (08/29/85)

My original posting concerned using Unix utilities like awk and vi for
Lisp, and modifications people found useful.  I didn't receive much of a
response, so maybe everyone out there is using Lisp machines...or maybe
it's hopeless.  At any rate, here is a summary of the replies.

One of my questions concerned using awk to select a list (it happened to be a
list of atoms, although I was interested in the more general case as well);
the list followed the word "features", although again the more general case
is also of interest.
 
Alexis Dimitriadis (tektronix!reed!alexis--hope I'm quoting these addresses 
correctly!) wrote me:

>   Personally, I find awk a rather weak tool for anything that cannot be
> conveniently parsed into fields on the basis of white space or some 
> replacement.  sed can do amazing things, (like, prepare a formatted
> index from Pascal source), but for something like the features list,
> I would just write a program, in my favorite programming language,
> that can keep track of the levels of nested parentheses.  It should be 
> a lot cleaner than faking it with awk.  

[Several others responded with similar comments, e.g. Tom Blenko  
<rochester!blenko> said, "I strongly suspect that the easiest solution to 
your feature-filtering problem would be to write the filter program in lisp!" 
--MM. Resuming with Alexis:]

>   If you are willing to assume that features lists are each alone on a
> single line, though, try the following:
> 
> 	grep -w features $* | tr -cs 'a-zA-Z0-9-' '\012' | sort -u
> 
>   `grep -w' matches lines with the _word_ `features' on them, 
>   `tr ...' replaces all strings of characters that are not a letter,
> 	digit or `-' with a single newline, (see the manual for tr,
> 	this is an example), and
>   `sort -u' prints one instance of each only.  
>  
> (Actually, I would rewrite that as 
> 	grep -w $* | ...
> Then when you call it, the first argument would be `features', or
> anything else you may be looking for. 

My other question concerned making vi sensitive to the type of file you were
editing (as indicated by the suffix; e.g. do a "set lisp ai sm" if the file
ends in .l, but not otherwise).  The solution I had ginned up was to alias vi
to a cshell procedure which checked the (possibly first file in a list of
files), and do a setenv based on the result.  One can also do this by a
"foreach" loop, thereby checking each file for whether it what its suffix is,
rather than just the first one.  I would think this might take more computer
resources, since it starts up vi afresh for each file, but I don't know.
Alexis suggested the following instead:

> ...You probably have some directories that contain mainly programs, and
> others that contain text files.  I find that most of mine have programs, so
> text directories are the `special case'.  So: In my .login I set EXINIT to
> autoindent, wrapmargin=0, etc.  In each directory that contains text files, I
> make a link to a .exrc file that contains the line `:se noai wm=10', etc.
> EXINIT gets read before .exrc, so all is peachy! (Unfortunately, $HOME/.exrc
> is read _after_ ./.exrc, so EXINIT must be used).
[N.B. See my note below--MM] 
>   Other prejudices:  If you want an easy way to convert between modes
> while in vi, try mapping the complete commands on some unused keys.
> Or put the commands in a file, and :source the file when you want to
> switch. (You can also use that to run ex scripts that rearrange a
> line, etc.).  And another thing:  Try to avoid cshell scripts, csh
> takes forever to start up.  Your example would be much faster if
> written for the Bourne (old) shell, like this:
> 
> #!/bin/sh
> #Set vi appropriately to show match, autoindent etc. iff the file is lisp
> #(i.e. if the first file of a possible list of  files has a .l suffix)
> case "$1" in
> *.l)
> 	EXINIT='set ai lisp sm'
> *)
> 	EXINIT='set noai';;
> esac
> export EXINIT
> exec vi $*

With regard to the solution of having a .exrc file (or rather, a link to
one) in other than your home directory, I was not aware that this was
possible.  Is this an undocumented feature, or is it hidden somewhere?
My man says vi looks at ~/.exrc, which I take to mean the .exrc in my home
directory.  BTW, on my system (4.2 on a SUN) the .exrc file in the local
directory overrides the .exrc file in the home directory, so there's no need
to use EXINIT.  I have adapted Alexis's solution instead of my original
one; one advantage is that it lets you use flags for vi (-t, + etc.), which
my original didn't (the procedure tries to interpret "+" as a filename--I
suppose you could get around this, but it doesn't seem worth the programming
effort).  Hope all this helps someone...
-- 
Mike Maxwell
	When you're up to your neck in alligators, it's hard to remember 
	that your initial objective was to drain the swamp.