Comment by tra3 | Hacker News Reader

Comment by tra3 | Hacker News Reader

Parent Full thread

> (For example, when trying to test things out I haven't really found a way much better than typing into scratch, selecting code and running it while staring at messages....)

Are you talking about when you're noodling, trying to figure how things work, or actually trying to build something?

For playing around, I found that scratch works ok, but I found a better workflow.

I end up using a daily note in org-roam, with #begin_src elisp... I then tag the heading with :REFILE:ELISP: so I can always find it later. Basically evaluate everything inline within that org-babel block.

When I'm building something, or driving towards a specific goal, I use buttercup [0] to write actual unit tests. If I squint, it kinda looks like TDD.

Finally, for debugging of running elisp, take a look at edebug [1]. It's a pretty standard looking debugger (if you used something like gdb). By default emacs uses debug which is not as friendly.

[0]: https://github.com/jorgenschaefer/emacs-buttercup

[1]: https://www.gnu.org/software/emacs/manual/html_node/elisp/Ed...

Just stumbled upon edebug yesterday after looking through the options that you can put in a `declare` form and it's become an invaluable portion of my workflow; if I may ask a noob question, is there an easy way to keep a persistent eye on a closure or arbitrary set of a variables, and is there a way to debug-step through disassembled code? Totally okay if you don't know off the top of your head, I'll have time to search for these eventually.

> is there a way to debug-step through disassembled code

That's what I've been using it for. Once you find a function you're interested in, call `eval-defun` in it. Next time it's executed you should get a prompt with a stack trace and ability to step through the code (with `n`) or evaluate an expression in context (`e`).

> if I may ask a noob question, is there an easy way to keep a persistent eye on a closure or arbitrary set of a variables

I discovered edebug last week when I finally had to; so we're in the same boat. My guess is "yes" :)

Thanks for getting back to me! I didn't know about evaluation in the current context, which should let me inspect and explore the environment like I wanted to.

To clarify for anyone reading, `eval-defun` needs to be called with a prefix argument to instrument the first function, and `edebug-instrument-callee` (`I`) can be used to instrument the function following point in edebug's source-code-buffer, which I think is what you reffered to as a backtrace; I printed the edebug manual and brought it to work with me, in which I see that you can get a real back trace by calling `edebug-pop-to-backtrace` (`d`).

By `disassembled `, I meant bytecode, which after thinking about for a bit, maybe it could be done with lapcode, which is like bytecode made of s-expressions, but what I'd really want is a way to see the stack. Anyway, that seems like a whole 'nother beast, outside the scope of edebug.

Edit: I was looking for an evaluation list, see `edebug-visit-eval-list` (`E`) and `edebug-update-eval-list` (`C-c C-u`) c:

> I was looking for an evaluation list, see `edebug-visit-eval-list` (`E`) and `edebug-update-eval-list` (`C-c C-u`) c:

Outside of edebug I've used `trace-function` and `watch-variable` in the past for this.

Reply on news.ycombinator.com