Clojurians Log v2

added Options UI to atom: https://github.com/oakmac/atom-parinfer/pull/89

I think Chris is out until Monday, but v3 should be ready to go as soon as he looks at it

I think there was already a PR for that that was delayed for some reason, might be worth taking a look if you haven't already

(it looks really nice though!)

yeah, i looked at it! it’s a year old, and only defined a config schema. didn’t handle backwards compatibility with existing config files and didn’t sync with the api

ah, I see. okay, cool

chris plans on removing the smart mode option if enough beta testers like it. this options UI should get us more testers

I dunno, if Indent Mode is going to stay as a part of Parinfer, I don't see any harm in leaving the option there (unless you do plan on removing it eventually?)

but yeah, making the option easier to turn on should help a lot

I wouldn’t remove it

start writing v3 for emacs, but found it difficult to port, since I want to process buffer instead of text

@doglooksgood Do you mean that you want to process the whole buffer rather than strings split into lines?

It is said that emacs have better perf to modify text in the buffer directly, instead of take the string, calculate the new string, and substitution.

Do you have finished the v3 on Cursive?

Right. So the version in Cursive actually does this. I process the whole buffer, and create a list of edits that I then apply to the buffer afterwards.

I’m planning to try porting that to the JS version for v3.

No, I haven’t had time, but I’m hoping to next week.

So if you can wait till next week that might be easier. I think it’s a better approach, it’s almost certainly more efficient in any real editor, and you get things like caret movement for free - parinfer doesn’t have to track it.

Yes, but I think emacs and IntelliJ is different, I have to work on emacs version.

and I have no confidence on performance of emacs-lisp...😂

Right, but I think that the same algorithm that works better for me will also work better for you.

I discussed it with @shaunlebron, and he seemed to like the idea. If it works well for the JS version it may become the official version, who knows.

So I’m planning to try to modify the current v3 to use that approach, and then I’ll port that to Kotlin for the JVM version.

And you can also base your port on the modified JS version.

we provide our utilities, and parinfer algorithm call these utilities. the utilities can be something like insert text, delete text, etc?

Well, what mine does is I call parinfer with the whole string (which in my version is actually a CharSequence, so IntelliJ doesn’t even have to create a string for the whole buffer). Parinfer then returns a list of changes to apply, which are like insert, delete, modify.

Then I apply those to the editor.

@shaunlebron Is that parinfer use one result everywhere, and I can make it a global context?

@cfleming that means, you still have to deal with the whole buffer string?

@doglooksgood In my case no, because I can pass a CharSequence which I get from IntellliJ. That’s an interface which lets me ask for the next char, and IntelliJ internally handles the iteration over its data structures.

I don’t know how you would achieve the same in Emacs, if it offers something like that.

But assuming that it does, the algorithm uses that trivially.

Yes, that is possible in emacs too.

Ok, then assuming you’re porting the JS to elisp, you can use that and it will work fine. Then you’ll get a list of edits back and you just apply them to the buffer.

so, you are write a new version in JS?

I’m planning to try that this coming week.