Peter Seibel peter@javamonkey.com writes:

Peter Seibel peter@javamonkey.com writes:

...

Okay, I'm totally confused. I have a couple macros with lambda lists like this:

(defmacro with-gensyms ((&rest names) &body body) ...

(defmacro once-only ((&rest names) &body body) ...

It seems that a few weeks ago, when I used these macros Emacs would indent the bodies correctly, i.e.

Bah. More chaos. I just restarted emacs and SLIME and now *neither* macro gets indented correctly.

And more. I guess I hadn't loaded the definitions that time (though I thought I had). So I restarted emacs and SLIME *and* slime-compile'd the files containing the macros and I was back to uses of once-only indenting correctly while uses of with-gensyms are incorrectly indented. Sorry for all the confusion--i.e. welcome to my world.

-Peter

Helmut Eller e9626484@stud3.tuwien.ac.at writes:

Peter Seibel peter@javamonkey.com writes:

...

And more. I guess I hadn't loaded the definitions that time (though I thought I had). So I restarted emacs and SLIME *and* slime-compile'd the files containing the macros and I was back to uses of once-only indenting correctly while uses of with-gensyms are incorrectly indented. Sorry for all the confusion--i.e. welcome to my world.

I knew it. Changing the indentation is problematic.

This is caused by the new cl-indent.el file. The modified indent function disables the "with-*" thing by default, so with-gensyms is indented like a function call. If you load the macro definition, Lisp will tell Emacs that once-only and with-gensyms are macros and how to indent them. You probably have slime-conservative-indentation=t, so that SLIME ignores the indent hint for with-gensyms. Setting it to nil should help here.

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?

We still have the problem that the macro definition must be loaded on the Lisp side before it is indented correctly. Perhaps the "with-*" heuristic wasn't that bad after all.

Well. I'm actually quite okay with requiring that Lisp know about macros in order for them to be indented as long as they get indented correctly based on the lambda list. In fact, when I originally proposed forking cl-indent.el it was with an eye toward getting rid of kludges like the with-* heuristic in favor of letting Common Lisp tell us how things should be indented. Though if you go down that path we'll probably diverge enough from the standard Emacs cl-indent.el that the issue of sending them patches will become moot. (I'm also interested in seeing if there's some simplification of cl-indent.el to be had by abandoning backwards compatibility--there are a ton of comments in there about things that are done only for backwards compatibility. So, my points are these:

- SLIME is going to get blamed for bad indentation by non-emacs-wizard users, even it it's really being handled by emacs so we might as well control our own destiny.

- cl-indent.el looks like a mess. (I.e. I can barely understand it every time I look at it) Some of that is no doubt due to the inherent complexity of the problem. Some is due to the difficulty of solving the problem purely in emacs. And some is due to historical cruft. By moving to a slime-indent.el we have a chance to get rid of the second and third categories of complexity.

- Someday I'm going to write (unless someone beats me to it) a LOOP indenter that works the way I want. But I'd rather implement it in Common Lisp so I need an indentation mode that knows how to talk to Common Lisp.

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.

-Peter

On Mon, 18 Oct 2004 23:04:23 +0200, "Thomas Schilling" tjs_ng@yahoo.de wrote:

I second this.

<AOL>Me too</AOL>

And as far as the LOOP indentation goes: Go Peter! You know about the extension to cl-indent for LOOP that's floating around, don't you?

Cheers, Edi.

Helmut Eller writes:

Using Common Lisp doesn't sound like an advantage to me. Emacs Lisp has lots of stuff that make writing indentation code easy: regexps,

How do you write a regexp to match the following sexp?

Anything that can do that would be much better than what emacs is now.

"Pascal J.Bourguignon" pjb@informatimago.com writes:

Helmut Eller writes:

...

Using Common Lisp doesn't sound like an advantage to me. Emacs Lisp has lots of stuff that make writing indentation code easy: regexps,

How do you write a regexp to match the following sexp?

Anything that can do that would be much better than what emacs is now.

What are you trying to say? You can't describe a sexp with a regular grammar because sexps can be nested. You need a context free grammar or so.

If you want to parse a sexp use parse-partial-sexp.

Helmut.

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