I wasn’t aware of this change in VS Code. Sounds interesting. My last attempt was very close, but the last 5% almost finished me, and I didn’t even succeed. But it was me, not VS Code, I think. (Even if VS Code made me have to do things in roundabout ways, which I then failed to fully manage.) A factor here is that I am not a Parinfer user myself, so I don’t have those incentives to spend the amount of time it demands.

Gotcha, a pure good-will effort on your part. For my part, I have the incentive, but I’m absolutely clueless when it comes to VSC internals (or Parinfer internals, for that matter).

Here’s a thread about it: https://twitter.com/pappapez/status/1461018167002734592 In hindsight, I regret blaming VS Code so much for my failings. I am pretty sure it was rather technical debt in Calva holding me back. + not having the sense to secure the foundation I was building on. I think that if I do things in smaller steps, and in the right order, we would have Parinfer in Calva. I do have the incentives to have a look at the technical debt tripping me up in my last attempt. Might start there.

As I’m starting with zero understanding here: does a Parinfer implementation need to be aware of Calva at all, or could it be orthogonal? Would it collide with Calva assumptions?

This is just from remembering that back when I used Atom, Parinfer was a separate package to Proto-Repl, which took care of most of the rest that you want from a Clojure IDE.

It’s entirely possible to build a separate extension for this. That’s not how I would do it, though. I would build it into Calva and use the infrastructure it provides. Similar to how ParEdit is an integral part of Calva. But for someone else, building a separate extension might make sense.

I just noticed that @U061E2UBT had commented, long ago, on my latest Parinfer PR. I added a comment there as well, for completeness. Here’s the PR https://github.com/BetterThanTomorrow/calva/pull/1429

On the subject of separate extension. Such an extension already exists. But I think it’s abandoned by its creator.

I’ve tried some (a couple?) and they seem to have issues, possibly due to limitations in the API exposed. Yeah, if Calva provides good abstractions, it certainly makes sense to build it within its purview. If I’m using VSC, I’m going to be using Calva.

Depending on what has changed in the VS Code API, it could also be about how we hack around things. It was a while ago since I worked on this, but as I recall, I needed to make it play well with other Calva editing of the document, and all I had was some event handler for when the document changes, and that event handler didn’t even get to know enough about the source of the changes, so it got to be guesses and synchronization…

As far as I’ve gathered, Parinfer works best where you can insert middleware into document updates. I.e., event -> [middleware] -> editor update. When you can only react to a change after the fact, things become dicey. I bet this is true for more things than Parinfer.

Very easy to end up with weird race conditions if updates can’t be atomic.

Plus, weird a undo history, potentially.

@avocade What was the nature of the change that would make things easier for Parinfer?

@U06B8J0AJ any details on the new VS code api?

This is pure hearsay, I’m reacting to what @avocade told as a by-the-way. I glanced at the VSC docs, and as far as I can tell, I can’t see the scaffolding needed to work around the problems I listed above at least. The only thing that I’m spotting that might be powerful enough is this: https://code.visualstudio.com/api/extension-guides/custom-editors Seems like something that would yield a lot of power, at the expense of probably being quite a bit of work.

Btw @U061E2UBT @U0ETXRFEW, have we had almost this exact conversation before, or am I just having massive deja vu?

We had a similar discussion in #C0F2A0MJN way back. It was about someone else attempting to implement full Parinfer on VS Code, and failing.

vscode parinfer can be its own thing, but I see the benefit of packaging it like Cursive does.

Let me know if avocade ever elaborates. I suppose you could build your own text editor with CustomEditor if it’s not politically possible to submit a PR for synchronous change interception.

I was lobbying Panic Nova (https://nova.app/) about edit event middleware for a while, because it’s a fast, native editor, and I thought I might use it if it had Parinfer and a REPL at minimum. I made a working plugin with the limited API they had exposed, and explained what I needed from them to make it good. They have so far not created the necessary hooks, because they’re worried about editing performance. Maybe the VSC crew has similar concerns, with the difference that with CustomEditor, you’re in charge of the UX, not them.

I think a CustomEditor is unfeasible, because users will expect that the editor works exactly as a regular editor and that is a mix of tons of work + things not possible to implement.

I don’t know enough about CustomEditor to determine if this is true or not. Is it forcibly custom? Or can you start with a clone of a standard editor and tweak it?

There is no way to tell VS Code that it is the regular editor + something. It is fully custom. You can build it on the same tech, like Monaco and what have you. And you can make it look very similar to the regular editor. I think the problems might start at theming. There are some ways to get some of the theme in there, but the API is not meant for it, so it will get tricky. We used to build the Calva REPL window with a custom Webview (which is somewhat similar in this regard) and never could meet the user’s expectations. (We should have made it look totally different, probably, rather than go for mimicry). We had code for code completion UI and some more, but the regular editors are super rich… With CustomEditor you get help with editor things like life cycle and change events. I imagine that utilizing that will quickly land you in the same spot regarding the lack in these APIs, as we have with the regular editors. Granted, it would be in our power to add our own API, at which point, maybe a regular WebView would make more sense to begin with. All this should be labeled AFAIK. I haven’t explored this much, beyond the struggles with maintaining that custom WebView editor, which is now several years ago.

For sure, that doesn’t sound promising. I was hopeful that https://code.visualstudio.com/api/references/vscode-api#CustomTextEditorProvider meant that ~most of the normal stuff was in there already.

Yeah, it helps with the state management, for sure. In the editor we maintained we had to do keep track of undo and things, that a CustomEditor would have provided for us. CustomEditor didn’t exist when we added that editor, so it was never an option then. Another thing with CustomEditor and Webviews is that the VS Code team do not really prioritize bugs that you run into because you are trying to mimic the regular editors. We had troubles with keyboard strokes not being registered as they should, and my issue reporting it didn’t exactly get the attention I thought it deserved. I take it that they think that extending the regular editor should be done with the API:s for that, not going fully custom.

Sorry, been sick for 2 weeks in a bad case of the covids. If I had some more insights than this they were burned away, but most probably it was a case of reading too much into a comment – I'm just aching (ACHING) to get away from IntelliJ 😄 Always found Calva more compelling, but I've become a bit addicted to Parinfer these days. I guess there's always rehab.

Paredit rehab! 😃

Oh noez…

We can always go back to parinfer modes. At its roots, the separate modes are very stable and easy to implement.

I explored Smart mode out of duty to see what parinfer should become, after feedback that modes were asking too much of the user. I wonder now if the user's intention is best left unsystematized. "Inferring" one thing was fine— but inferring what the user wanted to be inferred was a bit much.

(Smart mode is the only thing problematic to VS code. Smart mode being the meta rules for inferring from an edit which of the two modes to apply: indent or paren)

For the record, my attempts where not even trying to implement smart mode. I was always inferring parens, and used the Calva formatter aggressively to keep things indented correctly. While things where not glitching out, it seemed to be enough to make things “always” work.

is clojure installed there? otherwise that will indeed fail

Yes it is installed, I can run clojure from the integrated terminal

that happens when the terminal that launched vscode doesn't have clojure on the $PATH

Yeah that I figured, but it seems like the devcontainer should have added that to the $PATH, and I can run it from the integrated terminal, that's why I'm puzzled

Interesting, maybe try configure .lsp/config.edn configuring a :project-specs of:

{:project-specs [{:classpath-cmd "/path/to/clojure" "-A:dev:test" "-Spath"
                  :project-file "deps.edn"}]}