Fork me on GitHub
#parinfer
<
2018-03-14
>
misha11:03:06

@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.

misha11:03:28

any mode, the latest cljsjs parinfer and codemirror

misha11:03:56

actual editing stutters even on 2 short lines.

eraserhd14:03:28

Successfully called the function from Vim!

eraserhd15:03:33

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

eraserhd15:03:56

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

eraserhd16:03:08

Ah, it has trouble with unicode characters.

eraserhd16:03:27

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

eraserhd19:03:52

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.

justinlee19:03:30

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

justinlee19:03:03

for the true ouroboros experience

justinbarclay19:03:14

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

eraserhd19:03:35

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

eraserhd19:03:01

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

dominicm21:03:17

And then we can run the wasm on neovim-node

dominicm21:03:46

Then we can run that inside project Detroit...

snoe21:03:03

@eraserhd what version of rust did you target?

eraserhd21:03:34

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

snoe21:03:02

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

eraserhd21:03:12

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

snoe21:03:21

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

snoe21:03:27

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.

eraserhd21:03:34

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.

dominicm22:03:29

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

dominicm22:03:51

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.

dominicm22:03:25

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

eraserhd22:03:04

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

eraserhd22:03:33

Oh. I guess yeah, buffer read.

snoe22:03:55

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

snoe22:03:10

“small/medium” file