Clojurians Log v2

thanks for sharing 🙂 for future reference, iiuc, the unification / merge effort of rewrite-clj / rewrite-cljs may involve more feature parity and api being more similar.

i am not sure what the state of namespaced keyword handling is atm but iiuc there used to be issues (and there a few other things that might be good to be aware of): https://github.com/clj-commons/rewrite-cljs/issues

I've tested here, seems working for me. I also tested and detects sets and reader macros, so it seems I can use it. I'll test this new implementation on my current Clojure project I'm working with and see if there are any issues

One question: I'm writing a new way of detecting forms. Now, the command evaluate-block should detect the "current block". The meaning of "block" differs from person to person, so I'm gonna ask here: what do you think: #?(:cljs 10) should probably be interpreted as-is, not (:cljs 10) #(+ 1 2) should be #(+ 1 2) or (+ 1 2)? @(:s state) should be @(:s state) or (:s state)?

What about '(+ 1 2 3), should be '(+ 1 2 3) (as a list) or (+ 1 2 3) (as a function call)?

My first reaction was that the reader macro should be included in the block "of course". But then I thought a bit more about it and I'm not so sure. The "form" is the bit without the reader macro -- and the reader macro takes that form and turns it into another form. So here's what I think I expect:

|#?(:cljs 10) => eval sends whole expression; #?(:cljs 10)| => eval sends just (:cljs 10) so that leaves a couple of interesting situations...

#|?(:cljs 10) => eval sends whole expression (I think that's non-controversial)...

#?|(:cljs 10) => ??? I can see arguments on both sides but I'd lean to sending the whole expression...

... but that also feels like an inconsistency because what is evaluated depends on where the cursor is?

@mauricio.szabo for '(+ 1 2 3), for one example of something done elsewhere, in emacs, i believe putting the cursor after the right-most paren and invoking M-x eval-last-sexp returns (+ 1 2 3) -- not 6. so it appears to be treating it as a list. perhaps emacs folk have punted on the idea of a block (unless there's a region defined) and decided to support only the case of looking back from where the cursor is. may be other folks know better.

it seems to me that for #(+ 1 2), it's more frequently going to be useful to interpret it as #(+ 1 2) -- if (+ 1 2) is desired, making a selection and using the evaluate selection command seems like it's not too bad.

similar story for @(:s state)

So the eval there includes the ' so it is (quot (+ 1 2 3)) that is sent for evaluation essentially.

yes, i think so

That would remove the inconsistency I was talking about above -- and would move me back to my initial "of course" position before I started overthinking it 🙂

lol

Inspired from Nikita Prokopov's syntax highlighting rules for Sublime, I began writing a Tree Sitter parser for EDN. Writing it for Clojure(Script) will probably be more difficult. Will that fix this?

Anyways, I'll ping here if I get anything working.

Agreed. All relevant reader syntax should be included IMHO.

Selection can always be done to get just the form.

Great, I'll look at all the cases. It's interesting to notice that if you're in the inner parenthesis, the reader syntaxes will behave differently than the expanded form - (quote (+ 1 2)) will evaluate to 3, as we're evaluating the inner block. Does it makes sense?

When working in a .cljc file (in this case, I’m working on routing, so I’m building the I/O on both sides concurrently), is there a key binding to quickly switch between “evaluate CLJ”/“evaluate CLJS”, as in the settings?

@henrik not yet, I'll add on newer version. I'll probably add a command to toggle between two configuration I'm also adding on a new version: "Prefer CLJ" and "Prefer CLJS" (the first one will evaluate .cljc as Clojure, and the second, evaluate as ClojureScript). There'll be also "Clojure only" and "ClojureScript only", that will ignore the file extension

👍 With four options, it might be better with four different optional keybindings, rather than toggling through each sequentially.

I thought about only toggling between the "Prefer CLJ" or "Prefer CLJS" versions, wdyt?

That’s enough for my particular requirements, but OTOH, there might be use cases for the other two that I’m not aware of. You could set it up to CMD+ALT+[1-4] for example, and know that CMD+ALT+2 shifts you into Prefer-CLJS without having to check the UI (because that’s what it is bound to). For toggling, you may need to check the UI to understand what mode it just switched you into.

Good news: I was able to implement the reader for evaluate-block that is able to understand the reader symbols!

Only a single side-effect ocurred: if you use #_(+ 1 2) I'm evaluating the inner form (it seems right to return it than just ignore it at all). But the "evaluate-top-block" is parsing the full form, with the #_. It probably is not what someone would want... ¯\(ツ)/¯

I think that's a reasonable compromise. I tend to use (comment ,,,) Rich Comment Forms for stuff I'm experimenting with rather than #_ anyway.

Nevermind, I was able to work-around it 😄 The thing is that I use the #_ a lot to test code, so it would not work that well for me 🙂