

Editor-independent advice for working with Lisp - vog
https://groups.google.com/group/comp.lang.lisp/msg/6e91e20f2f371b52?&noredirect

======
neutronicus
As an emacs user, one of the biggest contributors (other than SLIME method
list prompts and the like) to my appreciation for Lisp is Paredit[1]. If you
ever find yourself frustrated with counting parentheses, this is the thing for
you. Essentially, it only adds delimiters in pairs - so you never delete
closing parenthese, and provides functions for (| indicates cursor location)-

1\. 'slurp' the token on either side of a list

(|a b c) d -> (|a b c d)

a (|b c d) -> (a |b c d)

2\. 'barf' elements from either side of list

(a |b c d) -> (a b c) d

(a |b c d) -> a (b c d)

3\. 'drill down' into nearest list

(|a b c (d e f)) -> (a b c (|d e f))

4\. 'break out' of current list

(a b c (d e |f)) -> (a b c |(d e f))

5\. And more, like 'jump across next list', 'delete next list', etc.

Using any of these commands re-indents the code. It is the best method I have
ever encountered in any language environment for doing 'code surgery' like
placing existing code inside conditionals. I even use it for C (although it is
not nearly as smart about C/C++ as it is about Lisp, so the benefit is not as
great - c'est la vie. Perhaps one day I will attempt to hack decent C/C++
support into paredit). If I ever switch to vim, attempting to port paredit
will be the first thing I do, and, if I fail, no switch.

Well, that got long. Too bad the original poster on the newsgoup will never
see this.

[1] <http://www.emacswiki.org/emacs/ParEdit>

[2] 'slurp' and 'barf' are the "official" terminologies, by the way

~~~
ScottBurson
Yes, this is the right way to edit Lisp. It gives most of the benefits of a
structure editor without the downside. Balanced-delimiter editing makes Lisp
actually easier to edit than any other language. (I've been editing Lisp this
way since about 1980, when David Chapman and I implemented balanced-delimiter
commands for Zmacs.)

(BTW I'm sure Rob is aware of Paredit. He's been around comp.lang.lisp a long
time.)

~~~
neutronicus
By, 'the original poster,' I meant the poster whose question Rob was
answering. I guess that was unclear. I know he's a veteran!

------
neonscribe
The "killer feature" that Emacs brings is automatic indentation. Parenthesis
matching is important, but an easy feature for non-progammable editors to
support. Knowing how much whitespace belongs at the beginning of each line is
harder, and pretty much requires programmability in the editor. Once you have
had it, you will miss it when it is taken away. Manual indentation breaks your
"flow" while composing code. This is true in C-like languages, but it is much
more critical in Lisp, where there are fewer punctuation cues.

~~~
aerique
No, the killer future that Emacs brings is Slime.

~~~
malkia
The killer feature is the editor knowing what's going on in the image. For
example typing (blah - he can check from the current package - whether that's
function, special symbol, etc. - and if it's in a table of specially formatted
ones (if, when, unless, etc.) it can do better formatting. Not only that but
you can inform about this in the actual.

Same goes for Lispworks, and maybe for AllegroCL.

Difference is emacs communicates with slime to the swanked image, and if that
image hangs, your editor is still there - not the same with LispWorks and
AllegroCL (but if you are careful, and know when it can explode then it's ok).

------
srean
People complain about Lisp's parenthesis all the time. I _almost_ never found
them bothersome and this comes from a Lisp newbie. My editor is vim though,
not emacs.

The only occasion that parens have bothered me is when I have to read code
printed on paper. Some code pieces are too beautiful to resist the temptation
of taking a print out for a weekend reading, comment out bits with a pencil,
scribble arrows all over it etc. Its then when I have to match tiny parens
printed 2-up on a piece of paper that it gets frustrating, my eyes not being
what they used to be (but I still print 2-up).

A thought just occurred to me: maybe add a pretty printing mode to a2ps that
draws the parens in different sizes and gray scale values. May be some day.

------
fexl
Can someone recommend a Lisp that will behave properly as a scripting
language? By that I mean run quietly without a REPL, and honor this
convention:

#!/usr/bin/lisp

~~~
sea6ear
I believe clisp will.

see section 32.6.2. Scripting with CLISP in this document
<http://clisp.sourceforge.net/impnotes/quickstart.html>

~~~
fexl
Thanks for the suggestions everyone! I had a bad experience trying this with
some Lisp a couple of years ago -- I could not for the life of me turn off the
stupid banner printout, but I did manage to disable the REPL. At the time I
just gave up and moved on, but I'll give it another try.

The last time I actually programmed in Lisp was back in the mid-80s for my AI
classes at GA Tech. I liked it then.

