info-gnus-english
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Slime and Emacs Lisp


From: Tim X
Subject: Re: Slime and Emacs Lisp
Date: Mon, 10 Apr 2006 18:23:07 +1000
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> 5. O'Reilly has a book called something like Extending Emacs or Emacs
>>> Lisp Programming - I can't quite remember. It has some handy tips. 
>
>> I have "Writing GNU Emacs Extensions" on my shelf which is quite nice.
>
>> But back to being off-topic: Is there some kind of debugger and
>> inspector for Elisp like what Slime provides for CL? At least the
>> debugger I know from XEmacs is very basic and does not remotely compare
>> to Slime's. Any help is greatly appreciated.
>
> Check the Emacs Lisp Manual, looking for "debugger".
> I use `edebug'.
>
>

I echo Stefan's comments. Emacs has the basic debugger/stack trace,
but it also has edebug, which is very powerful. Personally, I've
always found the best debugger to be between your ears. I've used the
simple debugger a fair bit, but have only resorted to using edebug on
a couple of occasions. I find lisp with its very simple syntax means
90% of the time, any bugs I have are 'logic flaws' in my algorithm and
while stepping/tracing and watching variables change values can
certainly help, its usually (for me) faster to just look at my code
and run it through in my head. The whole development process with lisp
is very different to working with something like C. I use unit testing
a lot more with lisp and just work on an individual function until I
know its returning what I want/expect and then just move on to the
next bit. In C, I would often have to write quite a few functions
before I could get to the point of testing and would then find quite a
few bugs all at once. However, even in C, I rarely used a debugger -
most of the time a few useful debugging C macros and a couple of
asserts was sufficient. I really only ever used a debugger when
dealing with lower level subsystems and device drivers or possibly a
quick analysis of a core file to work out where the problem occured
and then start looking at the sources from that pint. 

I've found even when working with slime and common lisp, I rarely need
the full power of its features - maybe I'm just doing really simple
stuff. I'm also a bit of a dinosaur and started writing code before
all these really flashy IDEs existed - back then, getting your code to
work well with a debugger often took a bit of effort and the
information it provided was either difficult to interpret or too
verbose.

I'd strongly recommend just using the emacs debugger and edebg for the
more complex situation. When you find your at a point which is
difficult to debug, post some specific examples to gnu.emacs.help and
I'm sure you will get some good pointers. 

In the meantime, lets move this discussion to gnu.emacs.help rather
than continuing this off topic thread further in this group.

Tim 

-- 
tcross (at) rapttech dot com dot au


reply via email to

[Prev in Thread] Current Thread [Next in Thread]