This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-04-20
Channels
- # announcements (4)
- # babashka (10)
- # beginners (8)
- # calva (13)
- # cherry (20)
- # cider (9)
- # clojure (11)
- # clojure-austin (2)
- # clojure-europe (3)
- # clojure-norway (3)
- # clojurescript (1)
- # datomic (5)
- # dev-tooling (9)
- # fulcro (5)
- # hyperfiddle (5)
- # instaparse (1)
- # lingy (1)
- # malli (21)
- # matrix (1)
- # missionary (9)
- # off-topic (12)
- # releases (2)
- # ring-swagger (8)
- # scittle (9)
- # shadow-cljs (20)
Thoughts on extending Cider's defun-at-point to include unwrapped top-level expressions? I often find myself wanting to eval/inspect/tap the value stored in a var v, but simply typing out the symbol and C-c C-c 'skips' backward over it to eval the preceding form that's wrapped in a list/vector/map.
Then I'd either have to move point to EOL and recall the key binding for the corresponding (less frequently used) **-last-sexp command , or wrap it in a useless [v] / (identity v) - often the easier route.
For a more realistic example take the syntax for @app-state , it feels that something like cider-inspect-defun-at-point should 'morally' treat this as a valid top-level call to (deref ..) - admittedly a tiny amount of friction but one that I'm still frequently tripped up by
(I realise the 'defun' naming and behaviour was inherited from Common / Emacs Lisp at some early point in CIDER's history, just debating if it would be better to nudge its semantics towards Clojure's more general notion of 'top level forms' in a file – especially as other tools like Calva don't follow this arbitrary distinction of wrapped / unwrapped forms)
If you don't get an answer more interesting that mine, I'd suggest to create a GH issue. We could use a self-contained example, and your own analysis of the possible tradeoffs. Thanks!
Even though I subjectively don't think that eval-last-sexp is less frequently used (to the point that I view it as a more fundamental command than defun-at-point), I have to agree that the behavior where C-c C-c walks back and evaluates code unrelated to the code under the cursor is not very intuitive. Perhaps, it makes sense when the cursor is at the whitespace or the comment, but not when it's other code.
I agree. I had actually forgotten it doesn't operate on any top-level form, as the name is a bit of an misnomer - it's not supposed to evaluate the definition at point, but rather the top-level form at point.
But like @U06PNK4HG I use more eval-last-sexp, so that's why I probably forgot about this. 😄
Oh yes, I was definitely talking about my own subjective usage of the commands, should've phrased that better 😅 Also what I had in mind were the more specialized families of commands like eval-and-pprint, eval-and-tap etc, for which I prefer to only commit one keybinding to memory and M-x the rest of the time. And usually that ends up being the defun-at-point variant