[racket] racket-mode

I think we don't miss a conventional debugger in Racket (Emacs or Dr)
because, unlike say Python, Racket is not a shallow layer over some
unsafe amalgam of C and C++. Sure there is some of it left but our
crashes don't leave core dumps because most of them are safe. 

I agree that on occasion it would be neat to say "stop here and 
let me explore/modify the environment and the store." Most of the
time though you get away with printf because the language is safe 
I just don't consider it high priority until someone shows me a
really good use case. 

-- Matthias





On Feb 28, 2015, at 9:33 AM, Greg Hendershott wrote:

>> Don't make me want to go back to programming Racket in Emacs :-) 
>> But thanks for mapping Emacs back into the fold. -- Matthias
> 
> The more I do with racket-mode, the deeper my appreciation for
> everything that DrRacket does. It's really quite amazing.
> 
> Also the more I program in Emacs Lisp, the more I appreciate programming
> in Racket. :)
> 
> 
> p.s. The edebug feature in Emacs Lisp is one thing I do now miss in
> Racket. IOW I'm tempted to tackle using DrRacket debugger annotations,
> with an edebug UI in Emacs. Either per-function like edebug, or per
> module(s) like DrR.
> 
> Sure, I hardly ever want a debugger for Racket, in the way I used one
> heavily and religiously for C/C++ (to step through new code the first
> time instead of just hitting Run). After all we have the REPL, and
> functions. And TBH printfs usually suffice. So I hardly every used the
> debugger in DrRacket.
> 
> And yet. Sometimes it would be handy to set breakpoints and step through
> code. Now that I've done that enough with Elisp for racket-mode, I want
> to be able to do it for Racket code, too.
> 
> Aside from utility, there's just the raw challenge of making something
> like that work. At least it would be a challenge, for me.