Clojurians Log v2
emacs
Hi, I think I'm missing a piece in my use of cider, I spend my time editing a file and then evaluating a form. So I always have to move back to that form and evaluate then back where I need to edit the code. How could I make a shortcut to easily re-eval the form without navigating back to it's location in the source ?
So you wish to jump to a form in a comment block that calls a function that you are repeatedly editiong.
I use a mark for this
https://www.emacswiki.org/emacs/MarkCommands
I would set a mark on the form that call the functions and jump to that mark after editing.
Alternatively, create the comment block underneath the function you are editing, then you dont have far to go to reach the line you wish to evaluate.
In spacemacs, setting markers is easy. I also use G to jump to the bottom of a file or ' ' to jump back to the last change. Not sure how to do that in vanilla Emacs
https://practical.li/spacemacs/navigating-code/markers.html
TIL marks can be used like that, thanks
I do the mark-and-jump thing. Also, fwiw, it's possible to define unit tests in the function itself (`:test` metadata). Some pros and cons discussed here https://clojureverse.org/t/inline-tests-do-you-do-it/4083
I use Emacs projectile package to jump between source and test code, its very good.
A couple of other options:
• If the form you want to eval is, say, (map inc (range 3)) then you can wrap it in an anonymous no-arg fn and bind it to something:
(def f #(map inc (range 3)))(f) in the repl without much typing.
• You could send it to the repl instead of evaling it inline (eg cider-send-last-sexp-to-repl) and then use the up-arrow in the repl to get to it and hit enter to call it again.
i have a patch for register insertion in inf-clojure, and here's a gist that accomplishes that in CIDER: https://gist.github.com/dpsutton/7556cf1f4ecfc97da7b7e9d6dbf210c6
let's you save items into registers C-c x r s <register-name> (x r-egister s-ave) is the mneomic. And then the normal insert in repl map has a key x that prompts for a form to send to the repl
so highlight a form, save to a register (i use t for (run-tests) all the time), eval whatever you want, and send the form to the repl
The docs might be useful: https://docs.cider.mx/cider/usage/code_evaluation.html If you mean you need to selectively evaluate something other than what's at point or before it without navigating to that region, I don't think that's possible. How would it work? Furthermore, if you evaluate a form once then it should be fine until you change its definition. Running C-c C-c (cider-eval-defun-at-point), C-c C-e (cider-eval-last-sexp) or even C-c C-k (cider-load-buffer) when you make changes should be enough I think.
Thanks for the reply, I'm currently just opening a small buffer that only show that line i constantly need to evaluate, and jump there when i need. I was thinking that my non issue was more common than it seems.
Sorry, I must be missing something. Why do you need a separate buffer? Can't you have the form you want to evaluate in the same buffer that you have your code? An example might help 🙂
The separate buffer is pointing to the same file, just focused on the form that i need to reevaluate constantly. So this way I don't constantly scroll up and down the file. I often have a comment form at the bottom of a file and when I need to edit the top of the file I end up scrolling up and down every time I want to reevaluate.
Oh I see!
Hmm, I don't have a clear solution to your problem. Personally, during the early stages of development, while a function still doesn't have a proper shape and I have to change it heavily, I don't put it in a defn. I keep it in a comment form, like you said, so I have a single thing to evaluate. As soon as it's a bit more stable but still not ready, that's when I put it in a defn and add a comment block right after it, so if I'm not modifying it a lot, that works (for me) too.
I think this workflow should fit most other forms as well, besides defns.
I also tend to have a comment form at the bottom but find it too limiting during development so I add comments as needed throughout the file (and eventually turn them into tests or something).