Fork me on GitHub

Ok, I have done more tests with multiple builds and approaches to change build for repl. I tried to change calva.startCLJSREPLCommand to (do (require '[figwheel-sidecar.repl-api :as figwheel]) (figwheel/cljs-repl "front")) But in that case switch to cljs does not happen, even new terminal for cljs repl is not created (empty command has the same effect btw). Escaped "s break it? Then I tried this version: (do (require '[figwheel-sidecar.repl-api :as figwheel]) (figwheel/cljs-repl :front)) In that case it is called and new terminal is created, but I guess keywords are ignored:

user=> (do (require '[figwheel-sidecar.repl-api :as figwheel]) (figwheel/cljs-repl :front))
Launching ClojureScript REPL for build: extranet
My next steps: - I restore default calva.startCLJSREPLCommand setting. - I start repl and start figwheel with 2 builds: “front” & “extranet” - I connect with calva - At this point I see this in embedded “CloureScript REPL” terminal: Launching ClojureScript REPL for build: extranet - As expected I can do all cool stuff with only extranet-related files - I quit cljs repl with :cljs/quit in embedded “CloureScript REPL” terminal - I start repl for “front” in that same terminal:
user=> (cljs-repl "front")
Launching ClojureScript REPL for build: front
And I see prompt. - I open some front-related file - Nothing is available for front-related file, but I still can do everything for extranet-related files. Also “Calva says” reports an error: Error: clojure.lang.ExceptionInfo: No such namespace: hb.front.offers-list.checkboxes, could not locate hb/front/offers_list/checkboxes.cljs, hb/front/offers_list/checkboxes.cljc, or JavaScript source providing "hb.front.offers-list.checkboxes" in file <cljs repl> {:tag :cljs/analysis-error}. It is “front” file that I open for tests. (switch-to-build "front") does not help. If I start figwheel for only one “front”, then I can navigate through front-related files.


@il.tmfv: Thanks for doing all this research! What if you try this after the step where you can do all the cool stuff for :extranet: 1. Go to the terminal where you started figwheel with the 2 builds. 2. Do :cljs/quit and then (cljs-repl "front"). 3. Reconnect Calva. (This is somewhat what Calva does for switching between shadow-cljs builds.)

👍 5

Nope, it didn’t help. I thought terminal where I start repl (I like to do it in a separate iTerm window, could this be the reason?) and all new java(lein) instances are separate processes in some point of view. Also after reconnect is called all repl terminals look like this


I cannot write and eval there anymore


not sure if screenshot is visible to you


> new java(lein) instances are separate processes in some point of view. bad term, sorry I meant to say that they have separate instances of cljs-repl’s maybe just thinking out loud


When you reconnect, the terminal repls should exited and new terminal repls created.


I too use a separate iTerm window for starting my repl, so that is what I meant. I'll create me a multibuild project and see if I can figure this out. I'd appreciate an feature request for better support for this on the calva repo, if you have the time.


@pez sure Maybe it would be better to create project that mimics my project? I can do it today or tomorrow


If you create a project that can be used for verifying the issue and when the feature is supoorted, that would be awesome!


Ok 🙂 I will create an issue and provide link to this project in it


Wonderful. Golden star in heaven for you! (As we say in Sweden 😄)


Thanks! I wish I could do more for this project

❤️ 5

Anyone here using VSCode on a Mac?


And possibly with Vim bindings


Yes, at least with Mac, in my case, but i know there are some using vscodevim.


Are you using the default keybindings? I was trying to see if anyone set their keybindings for evaluating the forms a little different.


Might be more of the fact of vim being in insert/not insert mode and where the cursor is aligned causing issues with which form it picks up.


Interesting. Can you give some examples?


I had a lot of issues with VSCodeVim and Calva, especially with ParEdit


@pez Let me reset all my keybindings and i’ll write up some concrete stuff. I’ve been messing with it all morning.


eventually I got rid of vscodevim and am now using paredit navigation and a fancy keyboard with home row arrows


So much of it is finding the right balance between everything and is not particularly anything to do with Calva. 😛


I use emacsy key bindings for paredit.


Want to share your keybindings?


I’d like to pick up a programmable keyboard and put paredit on the spare keys or another layer.


I have a terrible keyboard right now that makes pressing cmd+alt+ctrl+shift combinations a pain.


do it, it's a rabbit hole and you'll never be able to type on a normal keyboard again but your fingers will thank you


I have an Ergodox Ez at home but I don’t code on that machine much. It’s @ work that needs something.


one useful tool for remapping on mac is BetterTouchTool I use a das keyboard 4c ultimate + btt


I am using karabiner to remap alt on this keyboard to cmd. But it’s missing keys to give the full range of options on the right hand.


I'm curious about command/insert mode and if that makes Calva select different forms for evaluation.


Ctrl+Alt+V Alt+E > Evaluate current form (or selection) in REPL terminal In Vim Normal mode cursor is on the tail “)” it will evaluate the sexp inside of the currently selected position.


I have a hard time moving the cursor outside / beyond the tail “)”


Moving it below is causing a full file evaluation.


That eval command is broken, also w/o vim.


Try with the inline eval.


Yes Inlining works.


Are all repl commands broken?


I’m not used to inlining.


After I watched Stu’s scissors talk, I started to create (comment) based expressions at the bottom of files. But I often just sort of log what I do and eval to the repl.


I will play with inlining a bit and see how it flows vs putting it off to the repl.


We will fix the eval-to-repl commands. It was just that, since they are broken in what they select, they aren't a very good measures of wether there is a specific vim problem there. 😀


Makes sense.