Helmut Eller e9626484@stud3.tuwien.ac.at writes:
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.
You may be right--I haven't really had time to really try to grok it. However it does give me the heebie-jeebies just to look at it. All those huge functions, etc. I have to belive that there's some way to refactor it to make it a bit more accessible, even if we leave it in elisp. And refactoring is much easier if you don't have to worry about remaning bugwards compatible with some old version. I guess my point is that the typical reason not to fork something is because you lose the benefits of enhancements made to the mainline version. However in this case I don't think there are a ton of Common Lisp/elisp hackers out there hacking away on Emacs's Common Lisp support--I think they're all right here working on SLIME.
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.
Hmmm. I'm not sure what the worry about packages is. All the code I'm interested in indenting I'm also compiling, etc. so it has already been read by Common Lisp. And the advantages Common Lisp has is it actually knows what the symbols are--since SLIME knows about the current package, etc. I can ask it, what's the proper way to indent a FOO form and it knows which FOO I'm talking about.
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.
100% agreement. I'm an incrementalist. I favor refactoring over massive rewrites. I just prefer to have some room to work--the less concern about backwards compatibility the easier it is to make small changes for the better.
Keeping backward compatibility will make many people happy, too.
But at a cost. For instance, it seems--though I could be wrong about this--that there's code in the current cl-indent.el that indents according to some style that is no longer used by default. In the mainline emacs version they have to keep that code because who knows where there's some crusty old Lisp hacker using that mode who's going to throw a fit if he upgrades Emacs and his indentation changes. But he's not using SLIME. We can--I'd arguge--get rid of that historical code, and thus simplify our version of cl-indent.el because we know that SLIME users don't care about it. That's the non-backwards compatible changes I'm talking about. But again, all this is said with the caveat that I haven't immersed myself in cl-indent.el so this is more by way of slightly informed speculation than a specific call to action. So I'll shut up about this until I have an actual patch to propose.
-Peter