Actually even just \] on its own highlights the ] as an error.

Issue please! 😃 I wonder for how long we've had that problem. Is it only with square brackets?

:man-shrugging: So far only found issue if a closing square bracket is somehow involved in the parsing.

The exact result is a bit inconsistent, even within the examples already shown.

[\)]    ; ✅

;; Ignoring the lint-error about arity.
;  This is more generalized variant of 2nd identity example above.
([\)])  ; 💣

\]      ; error shown for ] immediately after \
[\]]    ; error shown for final ], while first ] treated as closing

Is it only the highlighter that goes wrong here? What about the structural editing? Does the cursor move correctly, or does it go out of whack too?

Just highlighting

Weird. Please file an issue. Shouldn't be too hard to fix, I think.

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

All bracket types are fully in play.

\)  ; 💣
\}  ; 💣
\]  ; 💣

I can't blame TypeScript for that mess. 😃 Personally I have spent too much time and sweat on trying to migrate. I don't regret doing that, but I am not keen on spending more of my Calva time on in that bin when I can spend it on trying to add value to the users. Still, @U9A1RLFNV has not spent enough time on this, he feels. 😃 There is a recent PR of his exploring if there's a way we can make it easy to choose ClojureScript for packages of functionality.

I’ve actually got a working solution I think, but it needs more dev and testing, and if it looks like it’ll work, then I need to update the package.json scripts, the build task, the documentation (both to explain the new project structure and workflow, and to update any material related to contributing that needs updating), and also the CI.

But I’ll once I do some more validation of the approach, I may discuss it more with @U0ETXRFEW before making changes to docs, scripts, etc.

Related discussion: https://github.com/BetterThanTomorrow/calva/discussions/1455. I plan to update that discussion once I’ve done more experimenting and validating.

> I can't blame TypeScript for that mess. 😆 Not really what I meant, just that it would give you some re-framing and distance from the original solution, which might help lead to a good direction out of the mess. > Personally I have spent too much time and sweat on trying to migrate. I suspected, but wouldn't know without asking.

> I’ve actually got a working solution I think Awesome. A reliable way to isolate CLJS from TS/JS while letting them interact cleanly would go a long way.

I think references will remain unidirectional to avoid issues, but I don’t think that will be problematic. The idea is that the extension itself will be built by shadow. So there will be cljs (ext) -> ts -> cljs-lib (cljs can also require code from cljs-lib). Maybe over time we can write more code in the cljs parts of the code base and move parts of the ts code to cljs.

I found ts->cljs->ts-> etc dependencies tough when i tried to do that in a project, I never found a nice way and scripted moving things around

curious how you're doing it, is this work in a branch/fork?

ah sorry it's in the PR?

@U0ETXRFEW are you against it overall or just don't want to prioritize it yourself?

@U63D7UXJB It’s in a draft PR right now

@U63D7UXJB I don't see the user value, which together with my battle scars makes me not want to spend time on it. But if it can be done: • without much of my time • without it creating a too weird tool-chain/build process/development experience Then I'm good with it. I celebrate the enthusiasm. There is a also the chance here, the way @U9A1RLFNV is going about it this time, that we can get hot reloaded TypeScript code, which would save me a lot of time, and I can see user value there.

this is clojurescript proper, not BB right? I guess another option would be to rebuild around a core which just bootstraps joyride?

maybe boots is a better word than bootstraps

Yes, compiled ClojureScript. shadow-cljs.

The thought of using Joyride for it has struck me. I find that very interesting. But we will need to make a choice. clojurescript + typescript + clojurescript + joyride starts to get too weird. 😃

I can't really imagine anyone feels like starting from scratch, but... It strikes me that starting from 0, and building on top of Joyride, to swap out whenever we reach feature parity could be pretty great, if we could actually get there.

I've been part of efforts to start from scratch to get to ClojureScript twice in the short history of Calva. 😃 My heart believes in rewrites. Which is why I've set out on those journeys, probably. But, no, I really don't think that's the way to go. Unless a separate team finds it to be a worthy task and does it in parallell, while the current code base gets maintained just as before, until the rewrite is ready to replace.

Did those rewrites leave useful code each time or does the rate of change in the calva codebase make them now or less useless now?

Oh, totally and fully useless. This was a long time ago and we never had much of functionality implemented anyway.

There are probably still branches around.

the ability to do it incrementally, either via easy clojure compilation or via building a shell around joyride as a kernel seems like it would improve the chances

Yes, definitely ^

I don’t see a rewrite as being very feasible. Calva has a lot of features. It would take a long time to get to feature parity, and that would be a moving target unless we halted the adding of new feature in current Calva, which I don’t think would be a good idea, as that would slow Calva’s development for quite a while, aside from bug fixes and dependency updates. I wouldn’t want to do that.

the tests are in extension-test, right? most are unit tests so wouldn't help very much to validate any port? not sure how extensive the integration testing is

It’s just a couple of smoke tests. We could port those to Joyride. It’s even fun writing e2e tests that way.

> I don’t see a rewrite as being very feasible. Yeah. I didn't really think that was a very realistic suggestion at this stage. Just verbalizing an ideal scenario. Maybe convincing people to allow themselves to share the dream for a few minutes can plant the seeds of useful ideas pointing in that direction.

In terms of motivating a dream, for me the dream would be to really hack hard on top of an integrated calva/joyride, and have spacemacs on vscode more or less, then the web platform and vscode reach gives you some advantages as an idealised platform

On the subject of rewrites: https://ericnormand.me/podcast/rewrites 😍

@U63D7UXJB please start a discussion on the Joyride repo about that dream. I'm intrigued!