This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (2)
- # beginners (32)
- # boot (10)
- # calva (81)
- # cider (39)
- # clojure (56)
- # clojure-europe (8)
- # clojure-italy (7)
- # clojure-new-zealand (1)
- # clojure-nl (8)
- # clojure-poland (1)
- # clojure-spec (12)
- # clojure-uk (38)
- # clojurescript (5)
- # community-development (1)
- # core-async (55)
- # cursive (3)
- # datomic (44)
- # dirac (15)
- # emacs (20)
- # events (1)
- # fulcro (57)
- # hyperfiddle (2)
- # jobs (9)
- # juxt (9)
- # kaocha (1)
- # lein-figwheel (1)
- # off-topic (93)
- # pathom (2)
- # pedestal (3)
- # planck (3)
- # reitit (15)
- # ring (10)
- # shadow-cljs (25)
- # spacemacs (7)
- # sql (19)
- # tools-deps (8)
Yes! There was an error in the file (which I was also using to test error output). Now I see that it is indeed re-evaluating... which I don't want. I have found and turned off the "Calva: Eval on Save" setting, but it's still re-evaluating on save, including after quitting/restarting VSCode and the REPL
Very strange. For me it immediately stops evaluating on save when I untick that option… No restart needed.
My file is just:
And the "Calva: Eval on Save" setting is unchecked. Whenever I change the value and save, the new value appears in Calva says.
(ns calvatest.core) (def c 25) c
FYI I'm often working with long-running expressions (hours at 100+% cpu), so it's not great if evaluations happen automatically or on save.
I hide stuff I don’t want to “run” when loading the file inside
(comment) forms. Calva has special top-level semantics for those and evaluating forms inside them is really easy.
I've used and like the
(comment) approach in some cases, but for using a file and Calva says as a REPL/worksheet you don't want to have to type that for every command (or get re-running of everything if you save).
No, just mentioning. The top-level support for comments is something most people don’t know about.
Is there some other setting or approach you can think of to turning off the auto-eval setting?
Or some way to say "Save, really just save"? I'd rather not run tests or do anything else either, just save.
VS Code does have a “Save w/o formatting” setting, but it will eval on save anyway. I just tested it.
Really, switching that setting off should just stop it from evaluating on save. I wonder what is going on….
Tests (of which I have none) appear to run on save:
Running namespace tests… No tests found. 😱, ns: 0, vars: 0
I wonder if maybe you have workspace settings overriding your user settings. Or vice versa, I am not sure which has precedence.
I see settings for running tests, but not on save. Where are separate settings? I'm changing things in Code > Preferences > Settings, in Code 1.32.3 under MacOS 10.14.3.
If I also turn off "Calva: Test on Save" then it stops either evaluating or running tests on save
So now saving just saves, which is what I want. FWIW I think that'd be a nice default 🙂
I’ll change the defaults for those on next major release, @lspector. I agree they can cause trouble. I’ll think of some way for Calva to try teach people new to Clojure about the need for evaluating things before other things start working.
FYI I'm often teaching people entirely new to programming (not just clojure), and would be more than happy to give feedback on additions/docs on this. FWIW I'm bringing my own gaps and confusions to the table too, not from being new to Clojure but from coding in research/academic/science/art settings mostly rather than traditional software development
That would be tremendously helpful, @lspector. We are preparing a new release with dependency injection and a much better REPL window experience. A rewrite on much of the README and Getting Started stuff will be needed and input on how those work for newcomers would help a lot.
Will the REPL window be different both from Calva says and from the terminal REPL? It'd be great to have one place that's perfect, but the proliferation is already a bit confusing
I think there will be a “Calva eval results” where those will go. In the first version that will probably still be a plain output channel, but it will later move to a window supporting pretty printing and syntax highlighting.
Will there be a single place where evaluated results and printed output and error messages go? My need is for one such place. It should be plain text that can be copied/pasted. Ideally it should include nothing extraneous like echoed source code or "=>" markers. It's good if it scrolls so that the most recent stuff shows. Pretty printing is nice if it's optional (one can just call a standard function for this, right?) but not otherwise. More or less the same for syntax highlighting (usually it would be a minus)
Syntax highlighting on values, printed results, and error messages? Most of that usually won't be code.
No. I try to keep the settings to a minimum. Evaluated results are always clojure data, so it makes sense to syntax highlight it.
Or if not default, that it'd be easy to get this. I guess if I cut and paste into a plain text editor, though, I could recover the plain text?
That's good. Probably not a big deal either way then. But out of curiosity, if the output contains the list
(map foo bar) is
map going to be highlighted as a function?
Also, this will all not be in "Calva says"? That means there'll be 3 sets of commands for evaluating things, with some sending things to the terminal REPL, some sending things to "Calva says" and also showing them inline in the editor, and the third sending things to the new REPL window?
To be clear, my interest is (maybe only) in having one, which shows return values, printed values, and error messages, in as unadulterated a way as possible.
In essence the new window will be like the REPL window, just without the input prompt. So it will be just output.
FYI was just looking at a student's machine, running Windows (I use Mac), and it looked like his Calva commands were slightly different? It wasn't clear to me which would go to the terminal REPL vs. "Calva says"
All commands sending stuff to the terminal are named like that. And often with the same default shortcuts as their inline counterparts, only with
alt-key added to the final chord.
So, to evaluate the top level command inline it is
ctrl+alt+v space and to send the current top level command to the terminal it is
He might have changed the shortcuts, but I don’t think he can alter the name of the commands.
I'm more likely to pull up the command palette and choose the command thatn to remember the chord, which is probably true of my students too. It might be nice if the actual command names could be more about the terminal vs. other option, I guess
I might have been confused about his list of commands because it reorders based on usage, so mine is showing up in different order
Yeah, that could be why. Type
calva term in the palette and all terminal commands will be filtered out.
Using the keyboard shortcuts is entirely voluntary. I have just tried to make it easy to know the terminal shortcut if you know the inline one.
I guess anything that doesn't explicitly say "in terminal REPL" is implicitly "in Calva says (or REPL window that replaces it) and maybe inline"... Is that right?
Maybe nice if there was just one option (the one I like 🙂), or if the naming was more explicit both ways
I don’t really see them as equivalent. The Terminal commands are there to make it easy to experiment with them at the prompt. I’ll have a think about the naming.
I think of them as two superficially different ways to accomplish the same thing: try some code and see what it does
So from my perspective it's a bit confusing that there's more than one, that they behave differently, and that neither quite shows me everything in the most simple way
A little extra confusing when it's not super clear which commands and/or setup steps are required for one vs. the other.
Whether code to be evaluated is typed/pasted at a prompt or in an editor seems like a minor difference, but in any case I'm interested in having all results and printed outputs and error messages go to the same plain text (and select/copyable) place, unadulterated (so without any annotations, and if someone wants it pretty-printed they could use clojure.pprint/pprint)
I mostly work in the files. But others like to do their experiments more often at the prompt. So Calva supports both.
I see supporting both is good! But clarity between them is good too, and getting all and only results/printed-stuff/errors to show up in a plain text place is key for me.
I hear you about the getting all results and stuff in one file. It will be syntax highlighted, that’s the only thing you won’t get rid of. 😃
I want to share a concrete example. With this code in a file:
If evaluate all of the expressions individually with "Evaluate selection or current form" then this ends up in "Calva says":
(ns calvatest.core) (defn foo [x] (println x)) (foo 13) (foo 17)
In addition, the return values (only, without the printed values) appear inline in the editor. On the other hand, "Evaluate current file" puts only the following in "Calva says":
=> nil => #'calvatest.core/foo out: 13 => nil out: 17 => nil
On the third hand, selecting all and using the "Evaluate selection or current form" puts the following in "Calva says":
Plus, the last "=> nil" appears inline in the editor. This last one is particularly puzzling for a couple of reasons. But I want to jump to what I hope to be able to get, via one method or another. What I'd like to see is either:
out: 13 17 => nil
nil #'calvatest.core/foo 13 nil 17 nil
That is, I want to see all explicitly printed text (unadulterated), and either all return values or just the last one. I've seen different approaches to the question of printing all or only the last value, and I think either could be fine. But I wouldn't want anything else in there (like
13 17 nil
The first one will be a bit like what will happen in the case of selecting all and evaluating it. The loading of a file is an nREPL op that behaves like it behaves so it will just print the last evaluated result (which I think is awesome for that op to do).
FYI. This will take a while before it gets fixed though. We have a demanding backlog to wade through first.