That sounds very cool! If you can maybe keep some amount of model/view abstraction going maybe we could get that into drr?<div> </div><div>Robby On Thursday, March 19, 2015, Greg Hendershott <<a href="mailto:greghendershott@gmail.com">greghendershott@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thank you, Robby. > Another approach that you might want to try is to catch the "c:c;c:c" > at the emacs level and instead of turning that into SIGINT (or > whatever signal it is) send an explicit message across to the "(sync > never-evt)" code that tells it to break the user's program's thread. > This is closer to what DrRacket does and it has the advantage that you > can still use the raw breaks to debug racket mode, should the need > arise (I find this very useful when debugging drracket -- but no one > expects a control-c to drracket to turn into breaking the program > running inside drr!) That's a good idea, too. Thanks! Speaking of breaks and deubgging: I have a `debugger` branch (pushed to GitHub, but not ready to be merged to master) with an experimental debugger. It uses the annotations from gui-debugger, which was a huge head start. Instead of a separate watch window, it draws top-level and local binding values directly in the source code buffer (somewhat like Light Table?). On my first pass, I was thinking of debugging as a Special Mode you're in, during which you break and resume etc., and then you exit. That worked OK, but it was too modal and "too special". So on my second (current) pass, you're in a special mode only while you're at a breakpoint. And it's less special in the bad sense: Now there's a full REPL available, extended with some debugging commands for Emacs commands to use (or you could type them directly as a human). A couple of the comamnds like ,(go) or ,(step) exit the special REPL and resume execution; others don't. And it's a normal REPL to eval code, not just for commands. In addition to entering the module namespace, for read/write access to top-level bindings, the prompt-read handler wraps your input in a let-syntax mapping all local bound identifiers to set!-transformers. So you can play with them interactively at the REPL. e.g. DEBUG:foot.rkt> (set! some-local (add1 some-local)) And so on, and eventually resume with those values in effect. Currently you can break only via breakpoints (although there are various flavors of these, including skip-N breakpoints, run-to-cursor, and so on). I also want to support breaking as a result of: 1. A statement you could put in your source (like `debug` in Elisp, or `pry`, or whatever). 2. exn:break, although I'm not yet sure how that will work. It's been fun to work on so far, although I'm scared I don't know what I don't know, and there are probably huge gaping holes. </blockquote></div>