[slime-devel] Re: Macro indentation redux

[Peter Seibel]

Helmut Eller <e9626484 at stud3.tuwien.ac.at> writes:

> Peter Seibel <peter at 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

-- 
Peter Seibel                                      peter at javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp