Alain.Picard@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