5 ms·

I bought Mastering emacs on a whim after reading it but am still looking for more in-depth stuff about working with Emacs Lisp in particular. I can do basic st

by rtpg 4y ago

I bought Mastering emacs on a whim after reading it but am still looking for more in-depth stuff about working with Emacs Lisp in particular. I can do basic stuff alright, being able to jump into source in particular is very helpful to at least find snippets of code doing what I want, but I don't have a good sense of how to work effectively in it. (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....) I would gladly pay money to watch somebody just write and debug emacs lisp code for half an hour cuz I feel wanting for usability when trying to work with this.

mickeyp 4y ago
You may like my article on this very subject: https://www.masteringemacs.org/article/evaluating-elisp-emacs https://www.masteringemacs.org/article/evaluating-elisp-emac...
tra3 4y ago
> (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 https://github.com/jorgenschaefer/emacs-buttercup [1]: https://www.gnu.org/software/emacs/manual/html_node/elisp/Edebug.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Ed...
- LanternLight83 4y ago
  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.
  - tra3 4y ago
    > 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" :)
    - LanternLight83 4y ago
      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:
todd8 4y ago
There’s already been some good replies to your comments, but I want to throw in one more simple suggestion. You can learn a lot about Emacs lisp by reading and modifying other developers config files. Pick a few of the more complete well documented configurations and go through them picking out useful parts that you can assemble into your own config. You will end up with just what you want and will learn more eLisp along the way. I’ve done this for years and found it very helpful. Also learn how to use the scratch buffer — e.g. you can write a function and try it out and see it’s output easily with [C-j], that’s bound to the eval-print-last-sexpr function. The built in help is amazing, there are at least 50 commands that provide some form of help or documentation, I use 3 very heavily: [C-h f] that’s describe-function, [C-h v] describe-variable, and [C-h k] describe-key.

by rtpg 4y ago

mickeyp 4y ago

You may like my article on this very subject: https://www.masteringemacs.org/article/evaluating-elisp-emacs https://www.masteringemacs.org/article/evaluating-elisp-emac...

tra3 4y ago

> (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 https://github.com/jorgenschaefer/emacs-buttercup [1]: https://www.gnu.org/software/emacs/manual/html_node/elisp/Edebug.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Ed...

LanternLight83 4y ago
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.
- tra3 4y ago
  > 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" :)
  - LanternLight83 4y ago
    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:

todd8 4y ago

There’s already been some good replies to your comments, but I want to throw in one more simple suggestion. You can learn a lot about Emacs lisp by reading and modifying other developers config files. Pick a few of the more complete well documented configurations and go through them picking out useful parts that you can assemble into your own config. You will end up with just what you want and will learn more eLisp along the way. I’ve done this for years and found it very helpful. Also learn how to use the scratch buffer — e.g. you can write a function and try it out and see it’s output easily with [C-j], that’s bound to the eval-print-last-sexpr function. The built in help is amazing, there are at least 50 commands that provide some form of help or documentation, I use 3 very heavily: [C-h f] that’s describe-function, [C-h v] describe-variable, and [C-h k] describe-key.