Fork me on GitHub
#parinfer
<
2016-04-05
>
cfleming00:04:09

Yeah, I agree, I think that’s going to be the change that will allow some people to use it at work who can’t currently.

shaunlebron00:04:26

right, I think that’s what all non-inferenced modes would converge to

cfleming00:04:30

What I’m worried about is how slurping and barfing will work without tons of commands.

shaunlebron00:04:46

lispy has that down

cfleming00:04:01

Yeah, I need to look at those modes again.

shaunlebron00:04:21

I mean, obviously you can’t map normal insertion/change events to those operations

cfleming00:04:42

This has actually been a great change in terms of figuring out how to handle all these things in IntelliJ - turns out I can easily hook things like delete line and tidy up the parens, which I didn’t realise.

shaunlebron00:04:47

it uses the vim-like hjkl keys to make it quick

cfleming00:04:50

That has been a killer for vim users.

cfleming00:04:10

Right, but it’s very context-sensitive. I can imagine it being powerful but it’s not newbie-friendly.

shaunlebron00:04:23

right, that’s the caveat

shaunlebron00:04:09

my hope is that the auto-mode and the parinfer-criticism can be realized as full thing

cfleming00:04:15

So I’ll need to go through and look at things like evil-cleverparens and see what to steal. They have some nice heuristics for fixing up pasted code which is something I’ve wanted to do for ages.

shaunlebron00:04:19

and for us to be able to compare tradeoffs

shaunlebron00:04:59

yeah, I think Cursive would be perfect grounds to explore that

cfleming00:04:00

Yeah, we definitely need a full implementation to see one against the other. What he discussed in that doc was a hodge-podge of existing modes, which even for an existing Emacs user is probably unrealistic.

shaunlebron00:04:20

but for Cursive...

cfleming00:04:45

And I’m excited to be able to remove the distinction between the modes and just compose the features as required.

cfleming00:04:55

I hope it works.

cfleming00:04:37

Ok, great to chat about all this - I’d better go and actually implement something.

cfleming00:04:42

I’ll let you know how I get on.

shaunlebron00:04:59

cool, thanks for all the context. chat with you soon, good luck

cfleming00:04:18

Thanks, seeya

cfleming00:04:39

@shaunlebron: Oh, one more question

cfleming00:04:13

With the tab stops change, I calculate the tab stops and if the user hits tab but their code is already at or past the last stop, I just indent two spaces.

cfleming00:04:28

I’m wondering if that is ever useful, or if it would be better to just not do anything.

shaunlebron00:04:29

ah, good point to bring up, yeah

shaunlebron00:04:51

nah, I think falling back on normal indenting is good

shaunlebron00:04:02

for example, for aligning a two-line comment

shaunlebron00:04:18

would be annoying to not be able to push the cursor to a certain point after a tab stop

cfleming00:04:24

Ah, yeah, good example.

shaunlebron00:04:51

so yeah, I think your idea is good behavior, two-spaces

cfleming00:04:12

Cool, that would be worth mentioning in the tab stop doc.

shaunlebron07:04:49

published 1.8.0 with the new tabStops feature

shaunlebron07:04:02

added tests and docs. changes are split by commit to make for easier porting: https://github.com/shaunlebron/parinfer/pull/110/commits

shaunlebron07:04:42

tab stops are not used in the demo editor yet

shaunlebron17:04:20

@cfleming: something I’ve had in mind since the beginning is allowing space and shift+`space` to indent/dedent selected lines by a single space. This would the user the ability to correct an off-by-one alignment caused by the usual two-space jumps

cfleming23:04:09

@shaunlebron: Right, something like that would be required in the auto-indent case, for sure.