Fork me on GitHub
#parinfer
<
2018-04-03
>
eraserhd15:04:15

@dave.dixon Are you sure? Same thing happens on parinfer-rust, and that's my understanding of how it operates.

eraserhd15:04:51

It definitely would be nice if it took the change into account. I wonder how to do that.

sparkofreason15:04:07

@eraserhd Positive, just sanity-checked now. It's probably why the behavior jumped out at me when switching from atom to cursive.

justinlee15:04:09

hang on, does cursive even have parinfer smart mode? I don’t see it as an option even

sparkofreason15:04:54

No. I think the Cursive implementation is "smart mode", but it looks like there are differences.

justinlee15:04:26

huh. i must have it misconfigured because it doesn’t do the thing where it “pushes” the lines below during insert

sparkofreason16:04:05

Looks like none of the "paredit" behaviors work in atom, and because of that I'm not in the habit of using those in cursive. That must be the trade-off.

shaunlebron16:04:47

@lee.justin.m smart mode is only in the early release version

shaunlebron16:04:57

in cursive i mean

sparkofreason16:04:13

I see now why it would be difficult to get this "right" without detailed context from the editor about exactly what changed.

shaunlebron16:04:16

@dave.dixon re: your example from yesterday—this should be used as the base for what behavior is canonical. can you reproduce here? http://shaunlebron.github.io/parinfer/demo

sparkofreason16:04:57

Yes. I understand why now.

sparkofreason16:04:24

What is expected in this case: (fn [a] (foo)), delete [, yields (fn a] (foo). Has the barf behavior if the [] are nested.

sparkofreason16:04:50

And the above is only observed for the single line case.

shaunlebron16:04:34

you can check the canonical editor again for an exact answer

shaunlebron16:04:54

but “paredit” behavior is something that I will not be advertising anymore

shaunlebron16:04:16

i didn’t really understand why it worked initially

shaunlebron16:04:26

but now i understand why it doesn’t work in these inline cases

shaunlebron16:04:20

there are two choices that parinfer has to choose from in the case you described

shaunlebron16:04:36

and it uses forceBalance option to pick one of the two

shaunlebron16:04:52

you can play with that option in the demo editor too

shaunlebron16:04:36

forcebalance on is super aggressive and will likely restructure your code in unwanted ways. forcebalance off trusts that you can fix the inline imbalances yourself

sparkofreason16:04:09

Got it. Thanks.

eraserhd17:04:10

Just got bit by a %s/short-name/much-longer-name/ in a file breaking indent.

eraserhd20:04:23

I think that's pretty much impossible with Vim. But I still want it 🙂

cfleming20:04:42

@shaunlebron Any idea why Atom isn’t exhibiting the canonical behaviour in @dave.dixon’s case?

shaunlebron20:04:58

@cfleming @dave.dixon can’t reproduce, i’d record a gif, but i’m screen recording a meeting right now

eraserhd20:04:35

hmm, /me has just realized that (x| y\n z), typing something doesn't push z to the right.

shaunlebron20:04:05

@eraserhd yeah the search/replace is a prime example of why all changes need to be passed to the parinfer’s changes option

eraserhd20:04:19

Oh... if I did that, it would work?

shaunlebron20:04:47

yeah, i have pages of these kinds of test cases that we are covering with the changes options

eraserhd20:04:20

ahhh. Hmm. I wonder if that's possible in Vim.