dev=> (up-since)
#inst "2021-09-25T23:37:12.873-00:00"

🙂

Sweet!

VS Code keeps processes in its terminals running and reconnects them between restarts. I think we can make the jack-in process persistent as well, since it’s using a pseudo-terminal, but I haven’t looked in to it.

Cool 🙂 I assume that this means you also use things like ns-unmap now and then? I tend to end up in a situation where I “have to” restart my REPL now and then.

Very rarely but yes, occasionally. You can see my hotkeys/shortcuts in my vscode-clover-setup repo (combined with my dot-clojure repo).

In particular: https://github.com/seancorfield/vscode-clover-setup/blob/develop/config.cljs#L71 but it's very rare that I actually need to use it.

That (using clover and custom commands) looks interesting, I’ll try that as well, thanks again! 🙂

I would be super surprised if a repl launched by calva would stick around even after closing calva/vs code

As you would be super surprised to see it stick around if you start it in an integrated terminal and then connected to it, right? It’s because that behaviour is new. Once VS Code users are accustomed to that, I think we will start getting questions about why jack-in behaves differently. But we’ll see. I doubt I’ll get the time to look into this before the questions arrive. 😃

Yeah, I wouldn't expect to have my terminals to go to a magic vscode land and come back when the ide starts again. I expect them to die 🙂

If you want them to die, then there is a setting for that. But default is that they hang around in magic vscode land. Which I think is consistent with other VS Code behaviour, keeping unsaved files around and such.

I'll go look for that setting right now, I could see this biting me when I have forgotten

Hm, I can see a setting for confirming whether to kill terminals, but not when to actually terminate them. Need to google a bit, I guess

I found a few closed bug reports about the terminals staying alive, but seemed like that wasn't the intended behaviour and was fixed. Also the VS Code docs say that the terminals will reconnect after a window reload, for example after an extension upgrades or installs. But nothing really about terminals sticking around after closing the IDE, and starting it again.

Ah, I might have it confused with reload. I almost never restart VS Code, but I reload the extension development host a lot.

Ok, sounds plausible. I've also tried to have something in the shell, but can't get it ever to come back after restart

Of course if something forked completely, it would be super tricky and really not even expected to die with the editor, but something like having an echo in a while loop straight in the shell does really seem to die

So I guess the conclusion is that long lived repls need to be, and should be, launched externally

Indeed. Even if many of my REPLs live for quite long, it’s not explicit goal I have.

I think the current system is very good. Calva can manage the repl lifecycle, or I can.

The only thing I could forsee ever wanting is an explicit detach command, where I notice that some calculation I started is going to take a while, so I'd like the repl to live on even after closing the IDE. Mostly to release the resources calva is using. But that's very theoretical, I'm not running out of ram due to calva

Do you mean detaching from an external repl? Would the disconnect command achieve what you want?

I mean the repl that the calva starts when doing a jack-in

Which way you evaluate? I haven't seen that behaviour, either with alt-enter or ctrl-shift-enter

Same with both:

Ah, I see! I think I'm never neatly just after the expression I'm evaling, but usually inside it

This behavior trips me over, in emacs the output text doesn't change the cursor position

It is partly because of emacs you stick your cursor neatly behind the bracket. 😃

I don’t like this behavior either. It’s a conflict with GitLense which uses :after CSS decorations, so we need to use :before. We could make it a setting for people who don’t use GitLense (or some other conflicting extension).

Surely then it conflicts with something else, that tries not to conflict with GitLense? I mean, having just two slots sounds just marginally better than one

It seems unusual with extensions decorating like this. Once one arrives and gets commonly used, I think both GitLense and Calva will start to get complaints. The API sucks a bit.

I just had a friend who’s learning Clojure and Calva ask me about this too.

What’s the deal with Gitlens? I don’t use it, but I see that behavior as well. I don’t think I understand what you mean, @U0ETXRFEW, regarding how Gitlens is related.

Looking at that extension screenshots, it seems to also put "stuff" next to the lines, and if that works with css :after and :before, different CSS rules would override each other

Exactly. We are decorating the last character on the line (the end-of-line character) with the results as content on a CSS :before style rule. Gitlense is using :after and would most often win the race (by being late to the party) if Calva also used that. So I switched to :before, with the unfortunate side effect that if your cursor is on that character, it will be pushed away by the inline displayed results. They are :before after all.

It’s unfortunate if there is not another mechanism for showing content in the editor like that, without actually inserting it into the file, and still having it stick around (which cannot be achieved with hovers, I think).

Consider putting some extra attention on this age-old VS Code issue: https://github.com/microsoft/vscode/issues/3220

A ton of thumbs up on this comment would maybe help (probably not, but anyway): https://github.com/microsoft/vscode/issues/3220#issuecomment-430124153

done

I think you see it in the output channel “Calva says” at startup.

You can also run the LSP info command (don’t remember the exact name) to get the version plus more info about the clojure-lsp instance running.

Not sure Calva installs its bundled lsp globally on the OS

I can’t unpack that sentence, @U0522TWDA 😃

Calva bundles Clojure-lsp, right? But unless it puts it in /user/bin or similar, I cannot just run it on the CLI. Of did @U9A1RLFNV an not CLI but Calla "lsp into command"?

There’s a Calva command for showing clojure-lsp info. It won’t show you a different version than what’s shown in Calva says, though. If you want to find the executable, you can use the VS Code command Extensions: Show Extensions Folder and you’ll find the executable in the betterthantomorrow.calva-2.0.214 directory.

Good catch! I think it is because he clears the output window now and then, it happens again at 5:36. Please file an issue about it. It should not be super hard to fix it, if we just decide on what the Ux should be for a stacktrace that is not examined.

Btw to everyone around: feel free to subscribe to Daniel's youtube channel, I really like the way he's making his videos - they're often short and informative. He already made quite a few! https://www.youtube.com/channel/UCKlYSDBb1KBcZyCRbniW1ig

> Please file an issue about it. Will do. :thumbsup:

Also, Daniel is a happy learner, so if you comment on his videos with tips, hints, questions, he will take care of your feedback.

Issue created: https://github.com/BetterThanTomorrow/calva/issues/1314

I added the link as a comment on the video. 😃

I don't see that comment you mentioned.

Neither do I. Maybe it got marked as spam.

Perhaps Daniel has to approve it as non-spam first in order to show up. We shall see..

If you, or anyone, knows about this, please PR. Maybe start with an issue. I copied that page from the wiki, I don’t recall who wrote it, but it certainly wasn’t me because I know zero about the issue. 😃

I am setting this up for myself so if I get it working, I will contribute it

Deal! And first an issue? 🥺 🙏

too late 😅 Will make it now

https://github.com/BetterThanTomorrow/calva/issues/1316

https://github.com/BetterThanTomorrow/calva/pull/1315