Clojurians Log v2

@cfleming: typed a response for this bug: https://twitter.com/CmdrDats/status/963346700357251072

i wonder if the production Cursive build is still using v1 behavior

@shaunlebron I actually can’t remember.

In the parinfer demo editor, with forceBalance on I get this: [[{| []}]]

Which is definitely not what you want.

@cfleming: that is what v1 did

I’m actually considering just always inserting balanced parens in parinfer mode.

(|foo => ()|foo?

You’d lose the slurp/barf-like functionality, but it seems a little unpredictable.

I mean when the user types an opening paren, always inserting the balancing closing paren.

So if the user types (, I’d add () and leave the caret between them.

Parinfer is the only editing mode which doesn’t act like that, unless the user totally turns paren balancing off.

So, typing ( at |foo => (|)foo

that would turn off wrapping behavior of (|foo => (|foo)

Right.

So if the user wanted to wrap they’d have to use the wrapping commands from paredit.

Those and Raise are almost the only ones I use still.

The wrapping commands are easy to remember in Cursive, they’re just Ctrl/Cmd + the normal key.

@cfleming: I think that’s a reasonable compromise to just auto-insert )

At least as an option, I think so.

The in-line inference doesn’t look like it has an easy solution.

boy I tried

i spent a long time last year thinking about that

Hehe, yeah, I know - I can’t remember all the details, but it just seems really messy

basically, it hit the boundary of what was possible by not looking at the content of the change

anyway, will explore what to do when pasting (( or deleting a ), since those are the cases not solved by auto-insertion of ) when typing (

that will be v4

Yes, better inference will still be very useful, no doubt.

from my perspective as a user I think you’ve done a great job “hiding” all this intricate behavior/logic, because I had no idea this was so hard a problem until I started looking into the implementation. I guess I assumed because it was pretty intuitive to use, it was probably ~easy to pull off 😄

process 2800 lines in 20ms

☺️

@taylor thanks for saying that, it should probably easier to pull off than it was, but i’m still trying to figure it all out

@doglooksgood whoa 🎉, what was the change?

some functions in emacs are really slow, I just rewrite for avoid these functions. but it's not a completed implementation yet. I use lisp-indent-line to do indent instead of calculate delta x. but it's looks almost finished.

I use parinfer everyday at work, and I am super excited for this new version to come out. Thanks for all the work you’re putting in.

but I can still feel lag if on a file large than 1k lines. just don't know why. file with 1k lines only take 9ms to process(do all work, not parsing). so it's still need avoid process whole buffer. but it's much faster than the current parinfer-mode.

but you’re still only processing top-level expressions right?

and it’s still lagging on 1kloc files?

no, whole buffer, 2800lines, 20ms

ah, cool! so you can avoid the lag with the top-level form hack atom uses

yes, that's pretty easy to achieve

man that gif is fun to watch 🙂

you even implemented the status message errors from parinfer?

yes, error will display.

It's better to show error position with overlay, but I haven't implement

some behavior is different with parinfer demo, for I let emacs do indent instead of preserve. lot of work need to be done for this.

I just want to update this as a new mode called parinfer-smart in current parinfer-mode when it's stable.

I need to port neovim's parinfer implementation if emacs is getting smart mode. Can't have that kind of imbalance (pun intended)

it's very nice that neovim can use javascript extension.

Very convenient, yes.

I think @eraserhd was working on this actually.

new version will come soon:grinning:

....I made mistake, is 160ms on 2800lines... no 16ms:sob:

faster than the old version. but not so fast

but after byte compile, it's fast again:sunglasses: