thank you @U0ETXRFEW for encouraging people to sponsor. I decide to sponsor you both monthly for a small ammount for as long as I can.

That's awesome @U011NGC5FFY!

I posted about this in #gratitude as well. https://clojurians.slack.com/archives/C02BJCKN0R4/p1648198331529119

Thanks @U011NGC5FFY and thanks @U0ETXRFEW for the shoutouts!

I did change stuff around this. And I have to admit I didn't try Live Share. But you do get the correct menu?

Is it working in 256?

The paths are correct, but different from local. Locally, the paths are absolute paths from the root of my file system. Over live share the paths are absolute from the root of the workspace. For example, locally I might have /Users/my/my-project and when connecting over live share that would show up as /. I can try with 256 later. It worked yesterday, but that may have been an even older version, not sure.

It was probably 256. I'll take a closer look at your commits for this and see if I can figure out what I didn't figure out this time. 😃

Thanks Peter! I like the 257 change by the way, as a poly user! 🙏

Poly-feelings about 257, then? 😃

Can you file an issue describing this, btw? I'm not using LiveShare often enough to be very reliable in judging when it works or not. 😃 The thing with different path roots is extra interesting.

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

Thanks! Here's a related issue https://github.com/BetterThanTomorrow/calva/issues/1613 can you add this repro there, pleaase?

Done. Hope it helps!

Wonderful repro. Thanks!

Thanks!

As for > I think I’ve spotted them here or there Is that within the same session, or do some sessions have rainbows and others not?

I just want to raise that VSCode now has native rainbow brackets and probably the Calva feature can be removed.

The Calva rainbows are going nowhere. 😃

Calva's rainbow brackets are Clojure aware and also work nicely together with Calva's rainbow indent guides.

Also, for clarity, the issue linked (and maybe also @U69US348Z’s report) is probably rather a symptom of the Highlight feature having some troubles. So it is not only about rainbows.

VSCode also has rainbow indent guides :)

@U0ETXRFEWz can you share some sample code with what you mean “Clojure aware”? I'm curious what I'm missing

The VS Code rainbow indent guides can't be configured to only highlight the Clojure current form. At least they couldn't last time I tried.

Re examples for ”Clojure aware”: Here's some test code we have in the Calva repo:

(a(b
   #?@(c
       #f
        (#b
          [:f :b :z])
       #z
        1)))
(comment
  1
  #foo
   #bar
    #baz
     #{:foo (#foo '[1
                    2
                    3])})

(comment
  
  #foo :bar
  (foo #foo ('foo^' :bar))
  #_ 'abc 
  #foo  @~#(foo 
             :bar) \space
  \' {:foo (#foo '[1 2 3])} 'abc
  #_#_
  #foo
   #bar
    #baz
     #{:foo (#foo '[1 2 3])}
  #foo
   'bar
  \a [] "a"

  )

"#########" ; 

Thank you! If I notice any patterns I will post to that issue. > Is that within the same session, or do some sessions have rainbows and others not? I’m not sure, I will try to keep an eye out and report back.

I think I fixed the issue some days ago: https://github.com/BetterThanTomorrow/calva/issues/1616

Great news! Thank you! I’ll report back if I see the issue again.

@U0ETXRFEW BTW I finally got around to taking a screenshot of the built-in VSCode rainbow brackets + indent guides. This is what it looks like with Calva disabled entirely.

And here with calva enabled

I was thinking about this use case of yours, @U0K592YDP, when I implemented the change. I think it should be fairly in reach to filter away the non-project files from that menu.

I don’t need any more filtering really – you’ve made the issue 95% better, and that final 5% doesn’t bother me at all.

It can trip new users up, though. But super good to know that it works well for you as it does. We'll see if we get any support issues from not filtering the list more carefully.

i.e. right now I just have to restart vscode after I run lein deps

Does "f1 developer:reload window" help?

Sort of. It's faster than completely restarting vscode. But I still have to start the repl again. From within lein repl I used to be able to do something like (use 'my-namespace.core :reload-all) and that would usually work.

You can just run the Jack-in command again even if you're already Jacked in. It'll close your current nREPL and fire up a new one with the dependency included. (Also, it automatically runs the equivalent of lein deps so you don't have to do that as a separate step.)

@U0383EA0A23 are you using Pomegranate in your project? I think that is the goto-tool for hot loading dependencies. The workflow depends on the use-case, but mostly it is to first use Pomegranate at the REPL to add and load libraries and see how things work. Then edit project.clj.

For cases when (use 'my-namespace.core :reload-all) works from the lein repl prompt, that will work from Calva's REPL as well, wether you do it from a rich comment or from the prompt.

@U034SN1AFM5 ah I didn't realize that! I assumed it would start multiple repls. Perfect, thank you @U0ETXRFEW I haven't used Pomegranate but I'll check it out, thanks

@U0383EA0A23 just checking, what are the reasons you are going with #leiningen instead of #tools-deps?

@U0ETXRFEW I'm very inexperienced and it's just what I happened to stumble across first

@U0ETXRFEW what are the reasons someone might go with #tools-deps instead of #leiningen?

tools-deps configures your project with data instead of code. 😃 I'm only half joking, it is more in the spirit of Clojure in other ways as well. Like only focusing on the dependency part of the project. Leiningen is awesome, but crams a lot of stuff into the same tool.

I'm not super opinionated, but I do recommend tools-deps over Leiningen even for a beginner. As a beginner what speaks for Leiningen is that it is so easy to create projects from templates. As a beginner what speaks for tools-deps is that that is the direction the Clojure community is moving.

We probably should take on the task of adding tools-deps versions of many of the more used/useful templates. Maybe there is more to making it as easy to create projects from templates with tools-deps as it is with Leiningen, I don't know... WDYS, @U04V70XH6?

@U0ETXRFEW That's probably a question for #deps-new since it needs more discussion around context (and isn't Calva-specific). I'm also not entirely sure what questions you're really asking here...

My question is more of general orientation. I like the convenience Leiningen has around this and would like to participate to bring the same convenience for people using tools-deps etcetera. clj-new makes it pretty easy to create projects from Leiningen templates, but those are often (always?) Leiningen projects. So I can see myself making tools-deps versions of some project templates. But beyond that I am quite unfamiliar with what's involved.

There are some deps.edn-based templates out there but there are no automated project.clj->`deps.edn` converters for the general case. Simple project.clj files can be automatically converted but for lein jar / lein uberjar etc you'd also need to add build.clj (or use my build-clj as a library). Once you get beyond the default lein commands, things get more complicated. Profiles sort of map to aliases (but not quite, due to lein's default profile usage -- which varies by command: repl, test, uberjar all use a different set of profiles, as I recall). Then there's ClojureScript build stuff in projects which I have no idea about.

And then of course there's the documentation issue: if a template's README is full of lein commands, adding deps.edn isn't going to help a lot of users since they won't know how to run the equivalent clojure CLI commands.

Thanks! I've converted some Luminus projects after the fact lately. I might start with that template. 😃

I think the best approach is a template-by-template one, sending PRs to the maintainer to adopt deps.edn -- alongside project.clj for the most part, rather than trying to supplant it.