Fork me on GitHub
#parinfer
<
2018-08-21
>
henrik05:08:35

@shaunlebron Perhaps this is something that the flex-tab thing could handle, if it was made to somehow play nice with parinfer. Parinfer to handle data structures, optionally flex-tab doohickey to handle alignment inside or between structures.

pez07:08:29

Thanks, @shaunlebron, I actually saw this reason for the behaviour, but I couldn't find a way to formulate it that even I understood myself.

pez07:08:02

While at it. Checked out Codemirror now and understand why I don' t see that sticky formatting enigma in the VS Code version. It is because I haven't found a way for Calva Formatter to help indenting new lines when Parinfer is active. What happens is that Parinfer is faster than Calva Formatter (which is currently using clj-fmt) and the editing commands that Calva Formatter calculates does not apply when Parinfer has done its things. It would be nice if we could find a way for solve this. But maybe it is something for me and the guy doing the vscode porting to sort out. Is he onboard on this Slack, perhaps?

shaunlebron16:08:51

@henrik wow you’re right

shaunlebron16:08:28

(foo \Tbar
 \Tbaz)
would expand to:
(foo bar
     baz)

parrot 1
shaunlebron16:08:42

actually, I’m not sure where the flex tabs should be to make that work

eraserhd18:08:57

I think the "sticky" case isn't a big deal, honestly. It will happen sometimes, but pressing backspace at the beginning of the next line should fix it.

eraserhd18:08:08

should means ideally, here.

eraserhd18:08:43

And this is all because we don't have access to the metadata about how certain forms should be indented. Which I wonder about what we could do if we pass that to parinfer.

eraserhd18:08:40

In any case, many cases aren't ambiguous, and even if it worked conservatively (didn't do anything weird in ambiguous cases), it would be neat.