We had a version of Calva, 290 I think, that failed to start clojure-lsp for people running earlier versions of VS Code. 291 fixes this by requiring the minimum VS Code needed. But if you are on an earlier VS Code then you won't be able to upgrade beyond 290.

The solution is to upgrade VS Code, and allow Calva to upgrade to latest.

Thanks @U0ETXRFEW - did that, all fine now

Strange. Now I find an error

Seems to be a version mismatch. Requires a newer version of VS Code

All working again. Strange

If you are using Calva jack-in, it should present Leiningen as a project type option. But maybe I am misunderstanding the question. Can you describe the steps you take and what you expect to happen that doesn't happen?

well I get this error now: ; Bad url: localhost:port

ok I'm running lein repl and did ctrl-alt-c... that seems to have done the trick

ok I think I got this working now... thank you @U0ETXRFEW

Great that it works! However, I'm still not quite following what happened, and would like to understand better. Maybe we can improve some messaging/Ux/docs...

I didn't read all the docs properly... so my fault... RTFM.

OMG. I can reproduce this.

I'm happy I'm not the only one 🙂

I think this is a Calva bug. Please file an issue.

Can you test with this VSIX and confirm that I have fixed the issue, @U201ZTKHB? https://output.circle-artifacts.com/output/job/872986cf-0cd6-4386-8d37-3f9e13e420a8/artifacts/0/tmp/artifacts/calva-2.0.294-1833-fix-wrong-version-evaluated-4f57de80.vsix

Yes sir

Works wonderfully.

Thanks so much for the super quick response!

You’re entirely welcome. Thanks for finding this. Scary bug!

Is the Notebooks stuff written up somewhere?

Found this: https://calva.io/notebooks/

Thank you!

Just as a test, I opened a pretty large file at and played around with it -- looks very cool!

Thanks, @U04V70XH6! It's very rough in this first shape. But already pretty cool. I really like the direction @U02EMBDU2JU is taking it. When we get some rich result views, maybe even #portal views, in there, I think it will start to be super useful for many people's workflows.

Happy you guys like it 🥳 I’ve already got a bunch of improvements I’d like to add

@U02EMBDU2JU Maybe an option to tap> the results instead of just display them inline? (i.e., change a setting for that notebook or maybe globally)

Why would you need the notebook at that point instead of tap> evaling in the text view?

I'm just impatient for the Portal views enhancement :rolling_on_the_floor_laughing:

hehe yeah me too 🙂 I’ve been told it’s in the works though 😛 but we’ll probably need some way to be less spammy on the output, but I’m thinking about something like “default collapsed output” or similar

btw a “fun” thing that came out of this is that anyone can write their own renderer for these notebooks. we’re writing the output as ‘x-application/edn’ and @U1G869VNV will “just” add a render for that to the portal extension. it would now be possible to add more types of renderers with other extensions: https://code.visualstudio.com/api/extension-guides/notebook#notebook-renderer

Oh... so the Portal extension itself can expose all of its viewers as notebook renderers and that will make all of that available directly to the notebook view?

One thing I wanted to try out: how does the notebook stuff handle top-level comment forms, given that Calva treats them as special, as if the enclosed forms were top-level?

Yes. We’ll probably pull that in at some point, just to make it easier to interact from the view into Calva, but for now that’s the easiest / most extensible way

Currently it doesn’t have anything special for them, so just one big thing that evals to nil. I’ll probably add handling that does something similar to Calvas own handling, so one cell per enclosed form in the comment.

Excellent! Thanks!

just not sure about how to “display” that. you’d still have to mark those as being in a comment. maybe a special “comment-clojure” language tag or something 😉

btw there’s a discussion on github to have a kind of keep track of the decisions around the notebooks: https://github.com/BetterThanTomorrow/calva/discussions/1825

I guess it's one thing I've never gotten about this whole notebook thing: how can you use it to write actual production code when it expects to eval every top-level form to produce inline results? The RCF comment approach comes close if that could be "notebooked".

Mhh, you’re probably right. In my mind, the notebooks were just a way of having a richer inline eval display and I’d remove most of the actual running stuff after I’m done, the same way I do in normal code. But I like the idea of treating the normal code as “incidental” in notebooks and making the actual notebooky stuff out of the rich comments.

I leave a lot of code in RCFs so I don't lose context/history when committing production code. That's my normal workflow. So "notebook mode" only works for me if it can somehow handle RCFs as if they contained notebook cells I guess.

It would also be pretty easy to have two types of notebooks. One that stays in this traditional style and a “rich comment notebook” that puts the whole file into one large code cell and then splits up any rich comments into their own cells.

As an example, when writing a date parsing function, I ended up with this RCF that stayed in the code next to production function:

(comment
  (for [fmts [(DateTimeFormatter/ofPattern "M/d/yyyy")
              (DateTimeFormatter/ofPattern "MM/dd/yyyy")
              (DateTimeFormatter/ofPattern "yyyy-MM-dd")
              (DateTimeFormatter/ofPattern "dd MMM yyyy")]
        dts ["1962-07-07" "2021-04-14" "7/18/1980" "10/5/1981"]]
    (try (LocalDate/parse dts fmts) (catch Throwable _)))
  )

(comment
  (def db-spec {:datasource {:dbtype "mysql" :dbname "worldsingles" :user "root" :password (System/getenv "MYSQL_ROOT_PASSWORD")}})
  (def derek (sql/get-by-id (:datasource db-spec) :user 9 {:builder-fn rs/as-unqualified-maps}))
  (site-user-key derek)
  (get-or-create-cid db-spec derek)
  (sql/update! (:datasource db-spec) :user {:siteuserkey nil} {:id 9})
  )

(and they don't necessarily get eval'd in order -- I often put setup and teardown first, then a series of explorations)

(comment
  (require '[com.stuartsierra.component :as component]
           '[ws.application-system.interface :as app])
  (def ^:private app (component/start (app/system {:process-id :test})))
  (component/stop app)
  (wrapped/seed (-> app :caches :site) {})
  (lookup-moods (:caches app)
                (:pooled-db (:database app)))
  )

That makes sense, my stuff looks similar, at least until my colleagues start hounding me to move more of it into tests 😅

Meh, this stuff is pure REPL-based exploration on a form-by-form basis -- it would look pretty different in test code 🙂

And I really like the idea of using those comments to bridge the gap between actual code and the notebooky stuff, thanks for giving me some new inspirations 🙂

BTW ctrl+alt+enter does not seem to eval a cell (if the cursor is inside the code)

yeah, there’s a special “Notebook: Execute Cell” hotkey. I still have to get a lot of the normal Calva tooling back up and running in the notebooks 😞

Notebook: Execute Cell is bound to ctrl+alt+enter but it doesn't actually work.

(selecting N: E C from the Command Pallete works, pressing the |> button next to the cell works, but the hot key doesn't, when the cursor is in the middle of the code in a cell)

ah interesting, it’s bound to ctrl+enter for me. Haven’t tried it yet though

It seems that Calva intercepts the hot key instead of the notebook.

Keybinding debugger:

[2022-08-18 18:05:01.220] [renderer1] [info] [KeybindingService]: | Resolving ctrl+alt+Enter
[2022-08-18 18:05:01.220] [renderer1] [info] [KeybindingService]: \ From 5 keybinding entries, matched calva.evaluateToCursor, when: calva:connected && calva:keybindingsEnabled && editorTextFocus && editorLangId == 'clojure', source: user extension betterthantomorrow.calva.
[2022-08-18 18:05:01.221] [renderer1] [info] [KeybindingService]: + Invoking command calva.evaluateToCursor.

yeah, we’ll have to extend a bunch of calva hotkeys to not “intercept” in notebooks or to do the correct thing

Ah, OK. So a known WIP.

Yeah, for some of them. I’ll probably forget a bunch at first 🙂

It seems that saving in notebook mode doesn't respect the editor setting to trim trailing spaces -- or is that a Calva-specific setting?

(I was messing with splitting and joining cells and then saved and got a change show up in git that was just whitespace)

Ah yeah, handling whitespace is one of the harder things about using the same file for notebooks and normal code. I have “format on save”, so I probably missed a bunch of cases. I’ll disable for next time and play with it some more

It's already very cool and impressive -- I can imagine it working really well for documentation with embedded code examples!

I have a big new feature coming up at work -- I can imagine using this for sketching some of that out...

Glad to hear that. Hopefully, I’ll get around to comment handling soon. That seems to be the highest priority to make it into more than a cool toy

Portal integration is coming along 👌

My biggest question is how to integrate all the various Portal features without cluttering the ui :thinking_face: I don't want have history/filter/viewer selector/command button/path for every single value.

I'm drooling @U1G869VNV!

I've taken to just cycling through all available viewers (I have a hotkey in Calva for it now), and I don't use any UI elements (I do that programmatically) so a way to just cycle the viewers for an active cell would be plenty enough for me.

Another question is how to integrate with the host runtime. Currently everything is based on serialized edn strings so anything that relays on a runtime (datafy/nav) won't work. Also, it looks like the serialized string don't include metadata, so no default viewers.

I think it's still valuable to have Portal as a full view alongside and the ability to tap> results, not just eval them inline (see my comment above about a per-notebook or global setting to do that).

@U1G869VNV I can provide a different output for different mime type. I’ll have a look to see if the repl result can give us metadata. I could also enclose the actual value with extra info like:

{:value "actual stuff"
:view-options ...
:any-extras ...}

As for the UI: I think the view selector and command should stay while losing the rest, but since we can provide extra data we could make it optional by passing in a config.

Not certain yet what the best way is to get runtime integration, but a “quick” way to get most of the way there would be a portal server in the runtime and passing in the port to the view so that it can connect to that. There’s probably a better/cleaner way to get more interactivity but this would get a bunch of stuff working I think.