parinfer 2017-08-16

@shaunlebron You asked the other day about the corruption problems with Cursive. I added a brain dump to the wiki about why this is hard: https://github.com/shaunlebron/parinfer/wiki/Problems-integrating-parinfer-into-Cursive

Let me know if that would be better somewhere else, e.g. in an issue.

The more I think about this, the more I think that I just need to notify the user when parinfer cannot be applied due to inconsistent formatting.

That’s a very annoying UX, but it’s less annoying than having your code broken.

And it implicitly means that users will only have to reformat their code when they actually want to modify a file, not just by looking at it.

thanks for putting together, will look tonight

that’s a lot of stuff

this reminds me of when I was at stripe

i once got some heat for taking too long to find a proper solution to a bug, when the solution was to just yank the feature I was trying to fix until it worked

✔️ 1

this feels the same. this is obviously too hard to solve quickly, and it’s breaking people’s code for however long it’s been out.

my gut is to pull it out until it works

added some headers to make it skimmable if it will help anyone else dive in for ideas

Right, and I think the tl;dr is that there is no fix for this in Cursive.

a screenshot since the anchor link takes so long to load:

on the one hand, it’s a given that incorrect indentation is going to mislead you about implied structure.

on the other hand, if users setup their code so that they can safely uncomment lines without thinking, then it is parinfer that threw a fork in their process and will take the blame for the broken code

it’s interesting because I never thought of Parinfer as breaking the UX of non-parinfer users

I’m thinking that this feature needs to be in parlinter rather than parinfer

it’s the function of parlinter to make collaboration between parinfer and non-parinfer users more possible

Yeah. The UX of non-parinfer users is where it falls down for me in regular basis.

it makes sense for parinfer users to see this:

(foo)
  ;; bar
but after parlinting before committing, it should be:
(foo
  ;; bar
  )

i’m not yet sure if parlinter is acceptable for projects, but it seems like a middle-ground to have this process in parlinter without affecting parinfer users

but it would only work if parlinter was adopted as pre-commit hook, which is probably asking too much

err, not a pre-commit hook, just as a normal part of the CI process

which doesn’t seem like a big deal to me anymore

i’ll move forward with that unless objections

a new parenAfterComment option that defaults to off in parinfer, and defaults to on in parlinter

Oh, you mean failing in the CI process.

So, this is probably obvious to you: Could parentAfterComment be turned on in parinfer?

yeah, i wouldn’t hide the option

@shaunlebron So with that option on, I would be able to edit files with the newline in?

@mattly thanks, i didn’t see that

What's the gotcha @shaunlebron?

i’ll chime in about parlinter to see if that would work here

I've turned down offers from places that prescribe dev tooling

i think linters are more and more accepted now

i only built parlinter after prettier became successful

to your point, I hope that linting can reduce the need for prescribed devtooling, if it’s just the formatting they’re worried about

I've had to fight an emacs bias at JUXT.

@shaunlebron I feel like there's a catch to the comment thing, is there?

i kind of described it as “comment-reversibility” in the issue, but I’m not sure right now

as a user it might be weird in some ways

as the developer, it has some weirdness i have to work through, but I’m not sure it’s too bad from user perspective. i’ll have to look closer and let you know

Okay 😛. I shall wait and see.

@mattly thanks for linking that thread, i added a comment

I should've yesterday when I saw it

@astrashe has joined the channel