Thanks for this report! I'd like to know details about issues with connecting and the formatter. And we want an issue about the Notebooks thing!

Yes, I’d be interested to know what “generating Notebooks” means 🙂

@domagala.lukas when visiting any file as a participant, instead of opening the file as a regular file it opens as if you chose "Open as a Notebook". The participant sees notebook cells instead of a regular Clojure file, and (if I recall correctly) the host sees a changed/unsaved file that must be closed manually.

@U0ETXRFEW sure thing - I'll try to gather more info and we can open some issues tomorrow :)

Interesting, thanks for reporting that. I specifically set the “open in notebook” as non default. You don’t happen to use any other vscode notebooks? Not sure if this is a vscode bug since that feature is pretty new.

I do not, but my colleague may -- I had not considered that! Thanks for the quick response and let me get back to you when I know more.

I submitted an issue - https://github.com/BetterThanTomorrow/calva/issues/1850

Thank you for the detailed bug report!

We have the same issue at work. Any new insights?

By the way, I updated the issue to add that after the guest opens a file (and hence sees it as a notebook), the host will then also see that file as a notebook.

I’m going to try and fix this. I reported an issue at the live share repo as well (https://github.com/MicrosoftDocs/live-share/issues/4765). If anyone has more information or hints on this issue, please let me know!

I've added some extra context as comments into the ticket. Hope you have more luck looking into this than I had 🙂

I think that that LS issue might benefit from an attempt to reproduce it with some other Notebook. And if it isn't reproducible like that, it might give some clues as to what we can do in Calva. (Really doesn't seem like there is much we can do in Calva, but anyway.)

Yeah just be careful what kind of notebook. The notebook API is pretty new and most extensions are still using some self built thing instead of using the official notebook API, so you might get “wrong” results

plus a lot of the notebooks use their own file extension, so they wouldn’t have the problem, which is probably why it wasn’t reported until now. if we used .cljnotebook files we wouldn’t have the problem either, but than half the point of our notebooks would go away 😞

Yeah, I also thought about a special extension. But we don't want to go that way with this feature. Quite disappointing with LiveShare acting up on a core VS Code feature like this.

Meanwhile, there is a total lack of activity on the upstream Live Share issue I reported. This problem is prohibiting me (and my colleagues) from updating Calva, which of course is a problem in itself. Can we think of some sort of work-around to move forward? Is VSCode notebooks implementation maybe assuming that notebooks always have different extensions and should we therefore also do that? (bummer) Fork of Calva without notebook support. (Also bummer) Extract notebook support into separate extension that you can choose to install/disable at will? (Maybe…?) Anything else?

We could maybe have a PR that follows the released Calva, with the only difference that it doesn't have the Notebook part of the manifest. Circle Ci builds VSIX:s for us on PRs, so then you and your colleagues could download those. Would that work? (I'm also counting on here that you maintain that PR 😃 )

That could work for a while, but is not really sustainable of course.

There’s a proposed notebook api change specifically targeted at LiveShare stuff. If that get’s merged into the main branch we can dynamically register the notebook and thus disable it in options. Let’s hope this happens soon.

That sounds great. Do you have a link to that issue/PR? I’ll upvote it 🙂

can’t find a direct issue. here’s the api: https://github.com/microsoft/vscode/blob/main/src/vscode-dts/vscode.proposed.notebookLiveShare.d.ts

https://github.com/microsoft/vscode/issues/147248#issuecomment-1137773838 > This will be a large, three-part change to the Live Share notebooks architecture, and our goal is to have this done by the fall. Fingers crossed…

upvoted it, let’s hope they manage to fix this. not a fan of any of the hardcoded project.json settings anyway 😞

The less of that hardcoded manifest stuff, the better!

@U0ETXRFEW I created the PR like you suggested (https://github.com/BetterThanTomorrow/calva/pull/1873). I’ll keep it updated and I’ll remove it once it is no longer needed.

Thanks! I think we should consider adding info about this to the published docs as well. Both on the LiveShare and the Notebook pages. WDYT?

Not sure. I would be OK with it, but it feels like a bit hacky work-around. I don’t think many people are actually using live share support (considering the multiple ways in which it has been broken in Calva over the past year). I’ll let you make that decision 🙂

It's hard to know how many are using it. I'm thinking that for the people who do, and who encounter that problem, they just might choose to check the documentation for help.

Yeah that makes sense

deps.clj is currently about 5 months lagging the official Clojure CLI (https://clojure.org/releases/tools), so this actually is a step backward in some ways. any chance @U04V15CAJ could sync and use a newer one? seems like maybe the work has already been done in the repo but not released?

the work is done, bb has always got an up to date deps.clj, but I'll release a new one now. since the "script" doesn't see much churn, you can actually get the newest tools jar by setting an env var, while keeping the script the same.

Thanks for this heads up. The deps.clj I replaced was several years old. 😃

Which env var is that? I can include this as a setting in Calva,

https://github.com/borkdude/deps.clj#deps_clj_tools_version

it's only fair that I release a new version more often that uses the newest tools jar

Yeah, maybe that is the best option here. Any user who want's to use a specific version of clojure can just tell Calva to use clojure instead and control the version that way..

We currently do not update deps.clj on the fly like we do with clojure-lsp. It is a hard bundle together with a particular Calva release.

well, if users start code with DEPS_CLJ_TOOLS_VERSION=... code . they get the newer jar that way too

they can put that in their .env files

Yeah, that too.

and they can also downgrade in case of emergency

Or set it in calva.jackInEnv

env vars are nice 😃

There you go: https://github.com/borkdude/deps.clj/releases/tag/v0.1.1155

I'd complain about this causing a problem for people who update their CLI but don't realize they also now need to update an env var -- except that I don't jack-in to projects, I start my REPL manually 🙂

yeah, I realize it makes it easier to not install clj, but when you do maintain your clj at specific versions, it breaks that expectation that Calva is using what you have at the command line. tradeoffs I guess.

Tricky trade-offs. People who have the CLI working could instead be using that to Jack-in. Calva quite clearly shows what it uses. We could show that even more clearly.

I am glad that it shows it the way it does, that certainly helps debugging mis-expectations