Dear Calva friends: calva https://github.com/BetterThanTomorrow/calva/releases/tag/v2.0.595
• Add: https://github.com/BetterThanTomorrow/calva/issues/2813
◦ Update default output destinations to all be [\"terminal\", \"output-sidebar\"] (from \"terminal\")
• Output views (both variants): wrap evalOutput at view width, avoiding horizontal scroll of the view.
• Output views (both variants): Add wrap toggle command for evaluated code and results
• Fix: https://github.com/BetterThanTomorrow/calva/issues/3270
• Fix: https://github.com/BetterThanTomorrow/calva/issues/3268
https://github.com/BetterThanTomorrow/calva/issues/3268
• Fix: More stable way to recreate the Calva Output terminal after the tab is closed. Mitigation for https://github.com/BetterThanTomorrow/calva/issues/3267
• Bump deps-clj to v1.12.5.1664
• Doc site: Let the Calva User Guide follow the system light/dark preference,
with a manual theme toggle and a Calva-branded dark palette.
• Fix: https://github.com/BetterThanTomorrow/calva/issues/3266
• Internal: Replace dependency on extract-zip for jszip (`npm audit` is clean for now)
So, there’s now an output view in the Calva sidebar. You can drag it to the Panel area, or to the right sidebar. And the output views now show evaluation meta (ns, session, runtime, who is evaluating), like the terminal output. Plus some more output view tweaks.
Also: @jonurnieta increased the performance of Paredit multi-cursor some 175X. 🚀
You've got a superfluous versions string in there now:
Calva Jack-in will use hardcoded versions of `nrepl`, etcetera versions when starting the repl.And I'm kinda surprised you didn't take the opportunity to update the versions. Any reason?
I ran into middleware problems with piggyback. Didn’t want to block on that.
Ah, interesting. I don't do cljs so I wouldn't notice 🙂
Latest available nREPL dependency versions found on Clojars:
nrepl: 1.7.0 (prerelease: 1.6.0-alpha3)
cider-nrepl: 0.62.2 (prerelease: 0.62.0-alpha2)
cider/piggieback: 0.7.0That’s what’s broken in this setup with you as the canary. 😃
output-sidebar isn’t there in the completions? The default is to write to both the terminal and the sidebar, with terminal as primary.
Oh, duh! It didn't actually update Calva 😐
Phew!
It said it updated it... But it hadn't... trying again...
The suspense, Sean! 😃
Okay, now the completion shows it! 🙂 And, yeah, I like that.
I can see myself using that... 🙂
I don't use the inspector (I prefer Portal) or flares, but having eval output available in the sidebar is a valuable option. Once I figured out ctrl+alt+o b to display it!
Awesome! And since we own those views, and they are webviews, we can add add nifty things (carefully, lol).
I place it below Copilot. Because I most often have Copilot chat open, but the left sidebar I often close, or shift between git and files and whatever.
Is there a setting to avoid Joyride Output and Calva Output auto-opening in the Terminal area? So I can just keep my regular bash Terminal open/focused.
(it's not a huge deal since they only open once at startup and I can switch back to my bash Terminal where my REPL runs, but...)
There are settings to not reveal them automatically I think. You can avoid the Calva Output terminal to be created by not defining at as output destination. But the Joyride output terminal gets created unconditionally. It also stops VS Code from creating a regular terminal, but a Joyride activation script can take care of that. 😃
Well, I guess Calva output has to go somewhere...
I find it good to have it go both to the sidebar and the terminal.
I only want eval results in the sidebar. But occasionally I need to look at eval output (not very often).
(Which is also the default now)
"calva.outputDestinations": {
"evalResults": ["terminal", "output-sidebar"],
"evalOutput": "terminal",
"otherOutput": "terminal"
},
My preference.Yeah, that makes sense. You can also pour evalOutput to a file.
Is there a reason eval results don't wrap by default? Is there a setting for that?
adds ctrl+alt+c alt+z to toggle calva eval output wrapping 🙂
It should follow your editor settings, and then there’s a toggle command. Reason being that that was the one of my design ideas for it that I choose. 😃
(to be clear, these are all just kinda grumpy first impressions, whenever I change my workflow, because I "changed my tooling" 🙂 )
We could add a setting for the wrap, instead of piggybacking on editor.wordWrap. Let’s see what we will want after some usage.
Ah, it follows the underlying setting, not the current toggle value. Hmm...
I'll have to give that some thought as I use it more. I typically have editor.wordWrap off but use alt+z to toggle it on/off as needed. I'll run with bounded for a while a see how I like it (or how much it annoys me).
It follows the underlying settings, and then that can be toggled.
Right, but there's no default hot key to toggle wrapping for Calva
(eval output) and I hate using the mouse.
bounded… I don’t know what will happen with that …
It works.
Wraps at the viewport (or the wrap column, whichever is smaller)
Yeah, but I didn’t think of that it could have that value, so am not sure what will happen.
wordWrap can have four values 🙂
I didn’t check. I just assumed it was on or off. 😃
bounded is probably the most useful TBH, since you can choose the wrap column separately. Then even if you have a big viewport, you can still force a wrap to "normal" terminal width so you can decide what to do with long lines 🙂
It should behave. I had done (not= "off" setting)
There ya go!
Pity that inline eval results don't obey the editor.wordWrap setting, but frankly, that is now much less annoying given the wrappable output in the sidebar...
The REPL session and ns text box seems awfully big, BTW...
Theme?
I’m using GitHub Dark Default. You?
I was using Dark+ on my OSS projects
(and Dark Modern on my work project)
I think it may be that evalResults is a bit small. But could be that I get that wrong. I’ll check what css I am using and maybe that explains it.
I use Font Size 14 BTW.
(for the editor, it's 18)
Yeah, could be that too. But the view doesn’t follow editor font size, afaik.
The clj: user part does. If I change my editor font size from 18 to something smaller, it affects that.
Ah, so probably we should make all text follow that pattern.
Very mystery
Maybe the GH theme overrides the editor font size there?
Where do you get that theme from BTW?
From the extensions tab, I think. I’ve been using it since it was released. Everytime I try to change I can only stand other themes for a few minutes.
It’s an age thing, probably. 😀
Did you notice if it made as difference for the font sizes in the output view?
It did not. So that is still a bit of a mystery.