Fork me on GitHub
#parinfer
<
2017-08-16
>
cfleming00:08:58

@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

cfleming00:08:10

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

cfleming00:08:10

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.

cfleming00:08:40

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

cfleming00:08:15

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.

shaunlebron00:08:11

thanks for putting together, will look tonight

shaunlebron06:08:26

that’s a lot of stuff

shaunlebron06:08:28

this reminds me of when I was at stripe

shaunlebron06:08:48

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

shaunlebron06:08:14

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.

shaunlebron06:08:08

my gut is to pull it out until it works

shaunlebron07:08:55

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

cfleming10:08:07

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

shaunlebron14:08:22

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

shaunlebron14:08:12

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

shaunlebron14:08:54

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

shaunlebron15:08:10

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

shaunlebron15:08:55

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

shaunlebron15:08:39

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

dominicm15:08:28

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

shaunlebron15:08:29

it makes sense for parinfer users to see this:

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

shaunlebron15:08:10

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

shaunlebron15:08:02

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

shaunlebron15:08:42

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

shaunlebron15:08:02

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

shaunlebron15:08:17

i’ll move forward with that unless objections

shaunlebron15:08:17

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

dominicm15:08:37

Oh, you mean failing in the CI process.

dominicm15:08:29

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

shaunlebron15:08:33

yeah, i wouldn’t hide the option

dominicm16:08:48

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

shaunlebron16:08:55

@mattly thanks, i didn’t see that

dominicm16:08:04

What's the gotcha @shaunlebron?

shaunlebron16:08:15

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

mattly16:08:23

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

shaunlebron16:08:07

i think linters are more and more accepted now

shaunlebron16:08:20

i only built parlinter after prettier became successful

shaunlebron16:08:32

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

dominicm16:08:08

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

dominicm16:08:18

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

shaunlebron16:08:17

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

shaunlebron16:08:42

as a user it might be weird in some ways

shaunlebron17:08:22

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

dominicm17:08:39

Okay 😛. I shall wait and see.

shaunlebron17:08:54

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

mattly17:08:14

I should've yesterday when I saw it