Peter Seibel peter@javamonkey.com writes:
Yes. That seems to fix my problem. So when slime-conservative-indentation is T it doesn't use any information from Common Lisp? And since you disabled the with-* heuristic it doesn't get it right just using elisp? But then why did once-only get indented correctly?
If slime-conservative-indentation = t, SLIME ignores the hints for symbols starting with def and with-. The with- heuristic is disabled in the new indent function so with-gensyms was indented like a function call. The hints for once-only are used independent of slime-conservative-indentation.
In other words, I'm much more interested in having an indentation mode that I can a) understand, b) extend/customize with Common Lisp code rather than more crufty elisp than I am in fixing emacs out-of-the box indentation. But that's just me and until I have time to actually cut code I'm just babbling.
The code in cl-indent.el may not be particularly easy to read, but I think it does a damn good job. It will be hard to write something substantially better.
Using Common Lisp doesn't sound like an advantage to me. Emacs Lisp has lots of stuff that make writing indentation code easy: regexps, forward and backward search, lowercase symbols without packages. You don't want to use INTERN or READ in Common Lisp for indentation because that clobbers your packages. No, I don't see what advantages CL could have.
The problems with the def-* heuristics could also be solved with something like (put 'default 'common-lisp-indent-function 0). The issue with backquote can be worked around simply by inserting a space blank before the form, like "` (do ". Both are very simple and pragmatic solutions.
My point is that abandoning cl-indent.el too early, is like throwing out the baby with the bath water.
I think we should at least identify some examples for which the current code fails and cannot be fixed easily before we do a massive rewrite.
Keeping backward compatibility will make many people happy, too.
Helmut.