This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-10-04
Channels
- # aleph (23)
- # announcements (1)
- # babashka (21)
- # beginners (70)
- # biff (3)
- # cider (8)
- # clj-kondo (45)
- # clj-yaml (9)
- # clojure (69)
- # clojure-europe (82)
- # clojure-nl (1)
- # clojure-norway (2)
- # clojurescript (34)
- # conjure (19)
- # core-typed (6)
- # cursive (2)
- # events (5)
- # fulcro (55)
- # honeysql (1)
- # integrant (18)
- # jobs (1)
- # lsp (124)
- # malli (10)
- # meander (1)
- # off-topic (26)
- # polylith (8)
- # reagent (7)
- # releases (1)
- # remote-jobs (1)
- # sci (2)
- # shadow-cljs (19)
- # squint (5)
- # vim (17)
- # xtdb (31)
This looks nifty: https://clojurians.slack.com/archives/C02BJCKN0R4/p1664830975305699?thread_ts=1664828065.167999&cid=C02BJCKN0R4
Hmm I wonder how it'd be implemented. I think not too bad with tree sitter but I think it'd be almost impossible without. You'd have to write a Clojure parser, so basically reinvent treesitter.
Would have to walk up to find the thread macro then drop the direct children below the cursor position. Then eval that
Would have to be language specific and only useable in languages that have threading macros. So on a client by client basis + some small integration code to describe the behaviour. And then they can all reuse a bunch of shared code.
I wonder how the other editors do it, if it's delegated to cider or something or if they're rewriting clojure on the fly
If I'm not mistaken, I don't think this thing would need to know about threading macros. It could just be an "evaluate current form up to cursor" operation
You'd need your cursor to be in a very specific spot though. Maybe that's fine. I was thinking it'd be smarter and walk outwards to the thread macro, but you're right. This could be generic at the expense of requiring more specific cursor placement.
I think knowing about the thread macro could be worth the trouble of doing something more specific. I like the idea of being able to do something like this:
(-> some-value
(do-a :thing)
(do-a :nother | :thing)
(do-something :else))
and just move my cursor up and down and be able to eval the thread form up to the step that I'm currently on.
The more generic version could be more annoying. I'd have to make sure that my cursor isn't inside of the parens of each form. At that point, I'm not sure I'd bother -- it might be easier at that point to do something like I'd do today and just comment out the remaining forms with #_
and eval the whole thing.Or wrapping the code in some kind of macro code, quoting the body, and having the wrapper code work on the inner code-as-data
My first idea is to use vim-sexp
and use sexp_move_to_prev_bracket
with visual mode. Then you could press <localleader>E
.
This is several keystrokes but it could probably be done with a command :thinking_face:
So if you bind sexp_move_to_prev_bracket
to (
then the key sequence could be this:
v(<localleader>E
.
But this wouldn't insert the )
at the end and it would say that there's a syntax error.
It could be fixed if evaluation function would try to balance the ending paren as it would only be one paren to handle.