parsing the file with 2.8k lines will cost 180ms in emacs.

not that bad, but about 10x slower than js

Maybe there's some way to optimize it? I'm sure most elisp is far less performance sensitive than this.

i think most elisp things aren’t doing the type of string building that parinfer is doing

planning on making parinfer return edits instead of a full string: https://github.com/shaunlebron/parinfer/issues/158

@shaunlebron It would be great to get that into mainline - I fixed that bug in the Cursive port yesterday, and it was due to the differences in char counting because I return edits.

So if mine could be more in line with mainline parinfer that would help me a lot.

@cfleming yeah, I definitely want that in mainline

sorry for the problems related to that, glad you found it

i don’t think i remember where that is right now in the js version

It complicates the editor integration a bit, because you have to specify the algorithm for applying the edits.

i see this: https://github.com/shaunlebron/parinfer/pull/170

Me either, I did have it in a branch somewhere.

Ah, that might be it.

Otherwise I can reverse engineer it from what I have.

It’s pretty simple.

i won’t be able to look at it this weekend

BTW when running the tests, I had to add a "use strict" to build.js, because it uses let

Is that specified by default somewhere when running using npm?

hmm, not sure

i bet it has to do with differing node versions

wish I could specify that in package.json, maybe I can

Ah, could be - I have no idea which version I’m using.

Anyway, I have a minor regression with two tests around error locations, but I’m hoping to be able to push a dev build today so you can check out the indentation marking.

sweet!

And I can get some more Cursive users trying it out too.

yeah, can’t wait to see what cursive users think. lot of parinfer users there

@doglooksgood Are you splitting the file into lines, or processing the whole file in one go? parinfer-js currently splits the file into lines, which makes some things easier but is not necessary. It’s also harder on the GC, and I don’t think Emacs’ GC is stellar.

@shaunlebron Am I correct in thinking that there’s actually no difference between result.lineNo and result.inputLineNo?

Actually, if that’s too down in the weeds when you’re not looking at the code, I can file an issue.

@cfleming: I’m 90% sure that they are always the same

there was a case where I was considering splitting lines when dealing with leading close-parens

yeah, line numbers should be the same

in the future though, I want to remove lines that are made empty by parinfer

for example:

(foo
  bar
  )

(baz)

(foo
  bar)

(baz)

@cfleming: ^

parlinter does this when used with the trim option:

--trim                   Remove lines that become empty after linting.