yeah it hasn’t worked either at all or stopped a year or two ago in my sole clojure project from work, but I always chalk up many LSP features not working in our project because it uses lein-monolith instead of polylith, so I haven’t bothered investigating this

do you use any other IDEs? I haven’t written any clojure in vim yet (my calva keybindings are too ingrained and onerous to port), but might be worth it to try out what projects you’re working on in both calva and another IDE that uses clojure-lsp to see if it’s really calva

it works just fine in intellij. vim or emacs i've never used

I’m unsure if intellij actually uses c-lsp

Confirmed that it does not

unless you’re using https://github.com/clojure-lsp/clojure-lsp-intellij specific plugin

https://clojurians.slack.com/archives/CPABC1H61/p1718847005909709?thread_ts=1718286554.390089&cid=CPABC1H61

@U037TPXKBGS found this one out!

VS Code is not Emacs. 😃

There’s a setting for this, though. calva.paredit.killAlsoCutsToClipboard

great, now i'm happy

I think it is a setting too much, but someone wanted it so much that he put in the work to add it, so I allowed it. Regretting it a bit, as it makes maintenance more complicated, but it is what it is.

FYI, you can give yourself kill-and-copy commands by using the runCommands command in a keyboard shortcut, then string together paredit-select-whatever and delete. When we added this setting runCommands didn’t exist.

A short runCommands intro: https://blog.agical.se/en/posts/vs-code-runcommands-for-multi-commands-keyboard-shortcuts/

Maybe I should implement the setting like that, come to think of it…

I think the main defining difference between Emacs and VS Code is the latter there is actually someone who has a sense of design and decides when there is a setting too much. It's my mine gripe re Emacs. They always just add more settings since some old fart can't be bothered to change his ways (it's always a he) in the interest of making things more streamlined, beginner-friendly or coherent. I really wish for VS Code and Calva to honour this spirit. Otherwise you end up with 10000 settings after a while and no fun maintenance.

So runCommand is sort of similar in scope to the progammatic form of Emacs kbd macros then. Without the interactive recording?

I like how Emacs is totally hackable. And that it is so while you are using it. It’s civilized. Luckily we have #C03DPCLCV9N, but it still a gap there.

There may be some recorder extension. Haven’t checked.

In theory, Emacs needs fewer settings than VS Code, since the latter is much less hackable. But then Emacs have been around a while and accrued settings. 😃

Yeah, I actually love Emacs. These days in seems like they spend 90% of developer time on technical infrastructure though, the stuff you get from Electron for free. For better or worse of course. In theory it should be less bloated, but on my machine VS Code feels snappier (perhaps due to better JIT and GC).

Calva exists because Emacs was too much for my poor Macbook 12 inch.

That's insane is it not

With native compilation it's probably better but the GC is what it is. And tree-sitter will probably be pretty great.

Hopefully VS Code will have tree-sitter as default too at some point.

But in Emacs any user-facing change will invariably (after much bike-shedding) be accompanied with a setting to preserve the old behaviour. I do not think it is ago itself that is the problem, but the lack of hard decisions on design.

I can recommend this talk on this hard decision subject: https://www.youtube.com/watch?v=-Bx2rmD7mN0

cheers, very interesting subject

another topic: is it the case that calva uses the same output file name for all repls?

i have a backend and frontend repl..

calva notices that the file is newer and asks if it should be overwritten

Calva uses the same output file name for both repls. But that is not why you get that message. That’s some glitch that we never have figured out. It’s mentioned briefly here: https://calva.io/repl-window/#known-quirks-and-caveats And it’s one of the reasons why Calva will stop using that file for output at some point.

ok. how do i prevent the repl file from being saved?

i don't remember opting in to do so?

You can’t.

OK. VS Code is indeed very opinionated.

It’s not VS Code. It’s Calva. And it’s not an opinion. Just a call we’ve made to not have to maintain a setting.

OK but in the above link it says If you save the REPL file (which most often does not make much sense, but anyway).

So shouldn't Calva default to not save it then?

The reason it doesn’t make sense is that it will be overwritten the next time you start the repl. I should remove that remark.

The reason Calva saves it is because otherwise you will have an unsaved file in the project that will keep highlighting as unsaved, which is annoying to many users.

So when Calva has updated it, it gets saved. With no way to opt out of it. Except now you can use some other output destination which will trigger the glitch less often.

perhaps the potential new repl experience will ameliorate this. anyway, i'm following the recommendation of having two separate vs code windows for a full-stack project. and i don't see how having two repls running will not run into this if they are connected to the same output file.

perhaps best to stick with one combined CLJ/CLJS repl?

Ah, yeah, that case is not covered well. I would say that keeping to a combined REPL is recommended.

Good talk! I can see why you opted for a single REPL per VS Code window, and I concur with this decision. But in the common case of having one CLJ Repl and one CLJS repl the association between windows and REPL instances should be easy. But then he considered the CLJC case, and you start. heading down a slippery slope..

That wasn’t really a decision. I didn’t know what I was doing back then. 😃

Well now you know!

I know that I have supporting multiple sessions very high up on my priority list for Calva.

Ok well there is good prior art to study then

https://clojurians.slack.com/archives/CBE668G4R/p1711631483080439?thread_ts=1711630683.865969&cid=CBE668G4R This only works if the given kill command has a corresponding selection command - killLeft doesn’t (yet at least) for example 😛

Good point, @U037TPXKBGS. It probably shouldn’t have a corresponding selection command. But it can keep implementing the setting with an ugly branching. Still a win to get rid of those branchings in all the commands that do have corresponding movement/selection.

yeah, makes sense, tho a little weird that killRight has a corresponding selection command but killLeft doesn’t

more importantly tho, we do have an option for how to remove the copy setting and letting users decide flexibly what to do

I didn’t recall that we had such a command for kill-right 😃 But maybe it makes sense to have it. (for both if so)

> more importantly tho, we do have an option for how to remove the copy setting and letting users decide flexibly what to do Please elaborate. But in a new thread, please. This is the craziest thread ever.

I posted that in this channel in a new thread already haha

We could consider to always add a an empty line after results. Can’t think of any reason why not right now. Maybe someone else can. Please file an issue.

Or we could print some info about repl session (clj/cljs) and namespace before each result. A bit like the prompt in the REPL window. That will take more work, though, because right now the output relay does not know about these things.

I would prefer a comment or white space, because it would be easier to work with the results.

You mean if you copy the result and happen to get the spacing lines with it?

yes, exactly. Comments or white space, like empty lines, wouldn't interfere but some other text output would.

FWIW I would prefer for nothing to be added at all. If something has to be added, blank space would suit me best.

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

It would be great to have a place that collects evaluation outputs and nothing else. And a place that collects printed output and nothing. Or they could go to the same place, but again, with nothing else. If someone wants something else then they can send it themselves. But if they want nothing else, but the system is adding stuff, then that's a bummer. Better if it could at least be turned off. But in my book the best default is that it shows what you asked for and nothing else.

@U06BV1HCH I’m open for a discussion about adding some kind of evaluation results sink to Calva. Possibly we could have a similar sink for printed output. I think a feature suggestion as an issue on the Calva repo may be a good start.

Thanks @U0ETXRFEW. It would more like an un-feature suggestion I guess 🙂, since I think what I'm looking for is just what the REPL output window used to provide. Do I recall that a legacy REPL window setting is part of the mix in the currently-envisioned future? If so, then maybe that will do what I want. I have to admit that I have mostly switched to using the CLI rather than Calva's REPL while this is in flux, so I haven't followed all of the details of the discussion.

I don’t think any of the current output destinations we have in place or are working on include something like this sink you want. They are for displaying results and other output sometimes together with context for interactive consumption. If something in your workflow needs something else it is a new feature we’re looking at.

If the CLI works for you, I think the current terminal output should work too. The terminal output destination shows less extra info than the CLI. But I could be misunderstanding the request completely.

Is the terminal output for things printed by println and friends, or for return values of expressions evaluated in the editing window? Only the former get printed from the CLI when running a program with clj -M /path/to/script/file.clj, although I've recently learned that I can get the results of all expressions in a file with clj -M -e "$(cat /path/to/script/file.clj)". In both cases I get nothing extra, which seems to me to be the correct behavior. Previously, when using the Calva REPL, I would get all of this stuff in the REPL window with nothing else, which was also good.

The terminal output prints less extra stuff than the REPL Window does and used to print. Not sure what we are discussing here.