Re: catching parenthesis errors in elisp

[rustom <rustompmody@gmail.com>]

On Jun 12, 3:18 pm, Tim X <t...@nospam.dev.null> wrote:
> rustom <rustompm...@gmail.com> writes:
> > Im hacking on a 700 line elisp function.
> > While doing some (fairly mechanical) cut-paste operations it looks
> > like either Ive got a parenthesis or a quote (most likely double quote
> > but could also be single quote) error.
>
> > Any suggestions on how to catch such errors?
>
> Have a look at occur and make sure you are using paren matching mode.
>
> For lisp, I'd also suggest looking at paredit mode. It is a mode that is
> very handy for editing lisp like languages. It has commands for
> manipulating the text as sexps, puts in matching () etc. Takes a little
> to get use to it, but once you are, it makes editing lisp like languages
> really fast an efficient.
>
> Personally, I'd also be breaking up the function - 700 lines in one
> function is a little excessive IMO. Apart from making it harder to find
> simple syntax errors, it makes it harder to hold the whole thing in your
> head conceptually and probably has lots of repetition (your reference to
> cut and paste makes me suspect there is too much repetition. Try to
> follow the D.R.Y. mantra (Don't repeat yourself).

Im only trying to make small changes to a 700 line func in org-mode.
[I dont think I could write a 70 line lisp function if I tried :-) ]
In making those changes Ive probably missed escaping (backslashing) a
double-quote is what I guess.
If I put the cursor on the start of the start
(defun org-export-as-docbook
and hit C-M-f I get unbalanced parenthesis 1, 27478
Putting it at the end of the defun and adding a close paren gives me
mismatched parenthesis.
Hence my diagnosis that its not a paren problem but a double-quote
problem

>
> My basic approach with lisp like languages is to write small functions,
> get them working in the repl and once I'm happy with them, put them into
> the source file. If I can't see the whole function in one screen, it
> usually means its time to break it down into smaller functions. If I can
> see lots of similar constructs in a function, then its almost certainly
> a sign its time to break the similar bits outinto its own function.
>
> HTH
>
> Tim
>
> --
> tcross (at) rapttech dot com dot au