[slime-devel] Re: Rape/Steal/Pillage

[Peter Seibel]

Alain.Picard at memetrics.com writes:

> Luke Gorrie writes:
> 
>  > > I'm thinking in particular of all the buffer-movement, narrow-to-X
>  > > and reindentation commands, for a start.
>  > 
>  > Which the buffer-movement commands do you mean?
> 
> I think you're right, after doing a bit more investigation.
> The first one I hit which really annoyed me was M-q which
> did not reindent the top level form properly (in SLIME).
> So I looked in ILISP, and M-q was bound to REINDENT-LISP,
> which is some gawd-awful complicated function which calls
> a gazillion other complicated functions to do its work.
> 
> Then I noticed the emacs provided indent-sexp.  :-)
> 
> so I guess reindent-defun could be trivially written
> as [save excursion [goto start of defun] [indent-sexp]]
> and be bound to M-q.
> 
> I too would rather import "as little as possible"; the 
> smaller the codebase, the better.  Maximize the number
> of lines of code not written, is what I always say.
> 
> 
> Lastly, I notice slime doesn't rebind lisp-indent-function
> to be common-lisp-indent-function; is that on design?  I imagine
> SLIME is essentially only used with common lisp, is it not?
> 
> And my current initialization file is full of crud like
> this:
>   (put 'setq 'common-lisp-indent-function '(2 6))
>   (put 'setf 'common-lisp-indent-function '(2 6))
>   (put 'unwind-protect 'common-lisp-indent-function '(2 &body))
>   ;; etc
> 
> to get common lisp indentation coming out "standard".  Should
> all this stuff be part of SLIME?

I'm just a lurker here but I'd argue that it'd be nice if the stuff
that doesn't *need* to be integrated with SLIME be teased out into a
separate thing. I've been using ELI with ACL for a while, after
previously using ILISP. While ELI has a bunch of cool features it
seems to also install its own elisp to do code formatting which it
seems to do less well than ILISP did. If both ELI and ILISP had split
their code into two distinct parts--a lisp/emacs interaction bit and a
mode for editing lisp source--then I could take the lisp/emacs
integration from ELI and the lisp mode from ILISP and be happy.

Anyway, I'll I'm really saying, is don't needlessly couple things.
(Now having not looked closely at the code for ILISP, ELI, *or* SLIME
there may be reasons to couple these things that I'm not aware of. But
it doesn't seem like they ought to be.

Unless of course one decided to use Common Lisp to do code
formatting--ship over a form to Common Lisp which then pretty prints
it back. Then if I want to change how Lisp formats my code I change
the pretty-print dispatch table. Which would be sort of nice because
then if I define my own macro that I want indented a certain way, I
can include some lisp code that gets loaded with the definition of the
macro code to fix up the pp dispatch table. The only problem with this
scheme that I haven't been able to work out is how to avoid losing
comments. Maybe use a slightly hacked read-table to read the forms
coming from emacs that makes comment "objects" which the
pretty-printer then knows how to print back out. Just thinking out
loud.

-Peter

-- 
Peter Seibel                                      peter at javamonkey.com

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