Fork me on GitHub
#calva
<
2019-04-20
>
hoppy01:04:30

@pez, back with you on dev branch. I've been working the previous snapshot hard on serious hacking, and it's been doing great.

hoppy01:04:47

whatever gremlyn was screwing up my fonts in the repl has left the building.

hoppy01:04:07

about to hit another hacking wave, so we'll see how dev stands up.

hoppy01:04:24

is there a plan to release to real VS-code repo ?

pez12:04:45

I've been removing some blockers for the repl window's release. Have one major thing left there. (The cljs repl window hangs when there are evaluation errors, and sometimes otherwise too.) And there is still quite a lot of work on the jack in. No ETA for when this can be released right now. But I don't think it should be very far away...

lspector15:04:55

On loading files on evaluation, and needing loading for evaluating expressions to work: I'm one of those who often has heavy computations that would happen on load (as in, they might take days), so I definitely don't want automatic evaluation ever. But I also want to be able to evaluate expressions in a file that has not been fully loaded/evaluated. This is in fact my standard workflow. And it's currently possible in Calva but using "Run selected text" (which sends things to the Terminal channel, which would be great except it also sends all of the code it is evaluating there, which makes it hard to see results and outputs and errors). I would really love this to also be possible with whatever new way of evaluating code will be the preferred one (the new repl window, it seems). If loading is necessary for evaluating individual expressions, the workaround would be to go and comment out everything first, load, uncomment, and then begin working. But that seems unnecessary considering that "Run selected text" doesn't need it.

pez16:04:56

Why don't you ”hide” the computations inside comment forms, @lspector ?

lspector19:04:02

I don't hide the computations in comments because I want them to execute. Just not when I'm only editing the file and evaluating expressions as I develop my code.

pez19:04:01

It seems a bit suboptimal to not be able to load the file, though.

lspector19:04:45

It can be loaded, but I only load it when I want it to run, not when I just want to edit it, or to selectively run other things in the file.

lspector19:04:24

This doesn't make sense for every project -- it depends on what the code is being used for, whether it'll be run interactively, etc.

lspector19:04:58

But as a general principle, I don't think things should be run without the user directing the system to do so.

lspector19:04:21

And it doesn't seem like it should be necessary just to edit, or to evaluate other expressions.

pez19:04:21

I don’t think we will have to make Calva load the file automatically w/o the user explicitly opting in on that.

pez19:04:04

But it is a fact that Calva relies on evaluation being done before it can deliver some of its services.

lspector19:04:06

As it is now, one doesn't need to load, and one can evaluate things, but only with the "Run selected text" thing

pez19:04:55

There is also static analysis, but that involves a whole lot of work that I just can’t afford to put in.

lspector19:04:24

I really don't need or think I want much more than is already provided with "Run selected text," except that the fact that that spews all of the code to the terminal, along with results/printed-outputs/errors is problematic, because it makes it hard to see the results/outputs/errors if you're evaluating a lot of code.

pez19:04:12

The terminal is soon history. 😃

lspector19:04:52

That will be great for clarity, assuming that the replacement does what's needed 🙂

pez19:04:23

I don’t think I understand why you need to send the text to the terminal.

lspector19:04:48

If I'm debugging a function and I add a println, I want to see what it prints

pez19:04:15

Ah, and that doesn’t happen with inline eval?

lspector19:04:28

The inline stuff gets layered on top of the editing pane, which doesn't work for large values, and I don't think it can be copied. I find that whole concept odd and when I've tried to get used to it I've been stymied by at least those two issues. I want everything (results/outputs/errors, but not extraneous copies of the code or prompts or anything else) to go to one plain text place, not on top of the editing pane, that can be treated like any other plain text place in terms of copying

lspector19:04:52

Most Lisp environments I've used over the years act this way, sending everything to the REPL. There may be a prompt at the beginning, and then the next REPL prompt at the very end, but in between will be all and only the results/outputs/errors from the code that I've evaluated

lilactown20:04:53

CIDER seems to default to not sending things to the REPL, which is where Calva took that from maybe

lilactown20:04:05

the default behavior is to show it in the editor pane, anyway

lilactown20:04:44

typically for large inputs, I use a different function cider-pprint-eval-last-sexp which sends the output to it's own buffer and pretty-prints the result for me

lilactown20:04:02

also allows for copy + pasting etc.

lilactown20:04:26

I think that would be a good compromise in Calva: for general evaluation, seeing the output inline in the editor window. for when one wants to copy-paste or view large outputs, opening a new window with the results with a different command

pez20:04:29

Calva shows the results in the output pane as well.