I normally realign after the changes with =ip

@U054W022G doesn't work with less trivial forms where the indents cross over after getting disbalanced

Not sure, could be different env? If I copy the above and insert set hit esc and then =ip I get:

(set (vec
      (list 
       1 
       2)))

I auto-format on save :thinking_face: So I don't even need to do = :thinking_face:

i don't think vim-sexp works with parinfer for that reason. vim-sexp doesn't move any other forms when wrapping forms, and parinfer works immediately to "balance" things

is there a command parinfer has that mirrors the vim-sexp wrap-and-enter-insert commands?

https://github.com/eraserhd/parinfer-rust/blob/9e41222b7bc8930e24c411c1b4bc48715975ed17/doc/parinfer.txt#L21-L23 Hmm, this would lead me to believe that it does/should work with parinfer.

> is there a command parinfer has that mirrors the vim-sexp wrap-and-enter-insert commands? I don't believe so.

Well if somebody has been pressing <localleader>i and then after that pressing =ip then you could make a function that would insert your text and then call =p automatically. Then you would be typing in the command window but it would be immediately formatted once all of the motions happen :thinking_face:

Yeah, but the =ip doesn't work for me anyway, not in cases like I showed above, which are common in real code. I actually have autoformat on save too, but nothing will really work if the indents get misaligned badly enough. It's that initial misalignment I'm trying to prevent. If, like @U054W022G, others are unable to reproduce the behaviour I'm seeing, I guess the only thing left is to binary search my config until I get to the bottom of it.

So does the formatting format in a bad way then? Or is it only during <localleader>i and after that the file saving fixes it? If I understand correctly you say that after you use this binding the formatting plugin doesn't even format the code correctly anymore :thinking_face:

I think if you have the code really misaligned, the autoformatting can't make a good guess anymore. e.g. I don't think any autoformatting tool can guess that the 2 here belongs to the list:

(identity (list 1)
          2)

I don't understand why 2 could belong to a list in your example either. Maybe the outer () but not (list 1) but then why do you call the outer call a list. It is a list because it's a list language but why would your next item belong to a list that you close yourself? Maybe you wanted to write this:

(identity (list 1
          2))

(identity (list 1
                2))

(list 1
      2)

(identity (list 1
      2))

(identity (list 1
                2))

I'm saying that if I start with this form:

(list 1
      2)

(identity (list 1)
          2)

ie. parinfer lags behind and closes the bracket when the alignment of the 2 gets behind the opening ( of list.

I don't use parinfer or similar plugins because they interfere with the parens that I like to destroy in the middle of my expression. And I want to delete and add new parens. This is the same reason why I don't like auto paren inference balancing. It's nice but it prevents me from deleting parens that I want to delete. And this is limiting because I sometimes want to destroy forms.

I use parinfer, and achieve the same edit by adding the start paren and letting parinfer add the end one.

So i(identity ? And not via vim-sexp?

Yes

(list
 1
 2)

() (list)
 1
 2

hah I don't know but something is definitely happening here

Your config is very smart. That's what's happening 😄 It's smarter than you even though you're the author 😄 We're doomed.

Have you turned off vim-sexp insert mode maps? Parinfer docs say it works better without them.

@U02EP7NKPAL yeah, I've tried that. Okay, you guys have convinced me, I guess it's time I rebuild my config.

You don't need to rebuild, you only need to do a binary search :thinking_face:

I think it all basically comes down to let g:parinfer_mode = 'smart' not behaving how I expect. If I change it to paren, it's much better in most cases, but doesn't seem to auto-balance parenthesis anymore.