Clojurians Log v2

@eraserhd go for it.

@shaunlebron can barely move cursor in parinfer-codemirror in ~300 lines of pretty printed 2-3 level deep map :( it looks like it is being called on cursor move rather than on text change.

any mode, the latest cljsjs parinfer and codemirror

actual editing stutters even on 2 short lines.

Successfully called the function from Vim!

And, it works. Rudimentary README with installation instructions for Vim. https://github.com/eraserhd/parinfer-rust

It seems to have trouble with some files. This might be errors in my porting. I'll be dogfooding from now on 🙂

Ah, it has trouble with unicode characters.

There are some unhandled corner cases with unicode characters, but with the last commit, it works.

Hey, so I optimized the Vimscript a bit, and now the file which was failing, which is the worst file I have to deal with, responds as fast as any other Vim command. Feels like there's no penalty for running it.

okay next step is to compile it to wasm and see if it is faster than the native atom version 😛

for the true ouroboros experience

Well I mean thats the second step, the first one is getting it working in Emacs <_<;

I have no clue how emacs plugins work; however, I would welcome emacs glue code in that repo if it's useful.

ha, I guess I still have emacs installed. I used to use it for Proof General.

And then we can run the wasm on neovim-node

Then we can run that inside project Detroit...

@eraserhd what version of rust did you target?

I think I just installed it last week. I didn't look at the version. I didn't use anything unstable.

k, I was still on some 1.19 version, just updated to lastest stable and it built

Oh, it just occurred to me that it makes the assumption that dynamic libraries end in dylib.

it works great! Still laggy around the bottom of clojure/core.clj but obviously that’s worse case.

I think in the early days @chrisoakman might have made an edit to the official lib for atom that assumes the start of a sexp is on the first column.

I saw that on the vim-parinfer plugin, but it messed me up in a file with a multi-line string that continued in column 1.

@snoe I think, while that's still in place, it's not considered to have a noticeable effect, given how fast parinfer is.

Are there benchmarks for those using other parinfer implementations with clojure/core.clj? I would expect rust to be one of the fastest. I'd be more inclined to blame slow read from the buffer than anything.

There is something in neovim about being sent diffs of a buffer... If read is the issue, that could be a solution.

I suspect the best indifferent there would be caching the state in a line by line basis and restarting fun the first changed line.

Oh. I guess yeah, buffer read.

we had some timing logs in nvim-parinfer but this might be the only captured timings. Within the cljs code we were running 5-8 ms on parinfer 1.6.1 https://gist.github.com/djwhitt/81f99794aa0c35b521f6

“small/medium” file