parinfer 2025-01-30

Just a heads up here: because of my work on Pulsar, I'm also working on updating and maybe modernizing some tools to better write Clojure and LISP code. One is Parinfer, originally made by @shaunlebron for Atom. Just want to give a heads up on some of the enhancements here, if that's fine with everybody πŸ™‚ One thing that I'm working now is to migrate stuff to Shadow, add hot-reload, and resolve some performance bottlenecks. So here's a screenshot of a profiling difference between the original code, and what I'm working now:

πŸ‘ 3

@cfleming luckily for me, I also control the editor's API so I don't have these limitations πŸ˜„. If Pulsar doesn't support something, I can just implement it in Pulsar hahahah

Wow, 39ms to 6ms, very nice. I thought Chris had already optimized it pretty heavily. Curious how you did this. (To clarify, I didn’t make it originally for Atom, that was Chris! I did core stuff.)

Is this the JS or the WASM version? I did half an implementation of the WASM version on https://nova.app. I had it working, but got stuck due to no way of transactionally running updates on edits (they run async, and spawn a secondary edit), and therefore a compromised undo stack.

Once a year I go into their forums and update a thread where I say β€œdo you have a decent API yet?” essentially

I don’t really have any intention to use Nova, I just thought it would be fun to add it to something.

> Is this the JS or the WASM version? The JS version. The WASM is slower πŸ˜†

(WAY slower)

@shaunlebron Oh, I see, i didn't know that πŸ˜„. Well, I profiled and found that split-lines was taking too long, so I found it was basically converting a JS array to a CLJS vector. I though that was the problem, so I refactored the code to never do this conversion, but it didn't change at all. So I though that maybe the split itself was the problem, so instead of getting the text of the editor and splitting it in lines, I used an API that returned only the lines. And that was it, basically πŸ˜„.

πŸ‘ 2

The limiting factor for Parinfer extensions is almost always the available editor API (ie: henrik’s comment). The performance of the core algorithm is rarely a problem.

FYI - there is probably a lot of low-hanging fruit here πŸ˜‰

Hahahhaa, I imagine so πŸ˜†. For now, I want to keep the same functionality, but somehow integrate a paredit on it - so that one don't interfere with the other, and things like "paste from clipboard without messing up parenthesis" become possible

The Atom's paredit is very limited and causes problems with cr+lf line endings

Depending on what you're wanting to do with it, this document might be useful: https://github.com/parinfer/parinfer.js/wiki/Problems-integrating-parinfer-into-Cursive. parinfer is written with some very simplistic assumptions about how editors work, and fitting it into IntelliJ was really hard. I've subsequently fixed most of those problems, but it's probably a useful list of things to think about. I no longer believe that an editor-independent parinfer is actually possible if you want it to be robust.

πŸ‘ 1