From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.user/7032 Path: news.gmane.org!not-for-mail From: Tim X Newsgroups: gmane.emacs.gnus.user Subject: Re: Slime and Emacs Lisp Date: Mon, 10 Apr 2006 18:23:07 +1000 Organization: Posted via Supernews, http://www.supernews.com Message-ID: <87psjp6dqs.fsf@tiger.rapttech.com.au> References: <8764lleqgk.fsf@tiger.rapttech.com.au> <87u095e2bu.fsf@missioncriticalit.com> <87d5fsslm4.fsf@tiger.rapttech.com.au> <8664liodk3.fsf@dellbeast.localhost> <87wtdyox68.fsf-monnier+gnu.emacs.gnus@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1144658447 10910 80.91.229.2 (10 Apr 2006 08:40:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 10 Apr 2006 08:40:47 +0000 (UTC) Original-X-From: info-gnus-english-bounces+gegu-info-gnus-english=m.gmane.org@gnu.org Mon Apr 10 10:40:44 2006 Return-path: Envelope-to: gegu-info-gnus-english@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FSrwo-0000tR-Qv for gegu-info-gnus-english@m.gmane.org; Mon, 10 Apr 2006 10:40:35 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FSrwo-0003by-57 for gegu-info-gnus-english@m.gmane.org; Mon, 10 Apr 2006 04:40:34 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!newsfeed.berkeley.edu!ucberkeley!sn-xt-sjc-02!sn-xt-sjc-07!sn-post-01!supernews.com!corp.supernews.com!not-for-mail Original-Newsgroups: gnu.emacs.gnus User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) Cancel-Lock: sha1:PVvmD3YFMuEBW1F3Dhv2aoCP1gM= Original-X-Complaints-To: abuse@supernews.com Original-Lines: 58 Original-Xref: shelby.stanford.edu gnu.emacs.gnus:77214 Original-To: info-gnus-english@gnu.org X-BeenThere: info-gnus-english@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Announcements and discussions for GNUS, the GNU Emacs Usenet newsreader \(in English\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: info-gnus-english-bounces+gegu-info-gnus-english=m.gmane.org@gnu.org Errors-To: info-gnus-english-bounces+gegu-info-gnus-english=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.gnus.user:7032 Archived-At: Stefan Monnier 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