Prev: wxcl
Next: Handling Ctrl+C interrupt in SBCL
From: Slobodan Blazeski on 13 Mar 2010 09:55
I'm writing a lot of CLOS code and with that the usual problem of
renaming arrives so I'm interested what kind of functionality does
Slime/Emacs has for refactoring common lisp code? Is there anything
like Eclipse Refactoring functionality?

thanks
Slobodan

From: Pascal Costanza on 13 Mar 2010 10:12
On 13/03/2010 15:55, Slobodan Blazeski wrote:
> I'm writing a lot of CLOS code and with that the usual problem of
> renaming arrives so I'm interested what kind of functionality does
> Slime/Emacs has for refactoring common lisp code? Is there anything
> like Eclipse Refactoring functionality?

As far as I know, not a lot has been done with regard to refactoring for
Lisp dialects. A reason may be that the regular structure of source code
in Lisp already makes it very easy to move code around (in advanced text
editors) that the added value you could get from a refactoring tool is
not that big anymore.

So, what problem are you actually confronted with?


Pascal

--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Helmut Eller on 14 Mar 2010 05:00
* Slobodan Blazeski [2010-03-13 15:55+0100] writes:

> I'm writing a lot of CLOS code and with that the usual problem of
> renaming arrives so I'm interested what kind of functionality does
> Slime/Emacs has for refactoring common lisp code? Is there anything
> like Eclipse Refactoring functionality?

No. To do that we'd need a database/indexer to model the source base;
it'd be very heavyweight, language specific, and a lot of work. Macros
and reader macros pose special problems. I've heard that macros make it
hard/impossible to write good C++ IDEs. It's easier for Java but I
think Eclipse needs more than 200 MB to build that model for a Hello
World style project (including the JDK classes). Much more for big
projects. This kind of IDE is only possible if you have decades of man
years to spare. Not a path we/I want to pursue.

Try to look at it this way: no Linux kernel hacker uses an IDE.

Helmut
 | 
Pages: 1
Prev: wxcl
Next: Handling Ctrl+C interrupt in SBCL