parinfer

henrik 2018-08-21T05:09:35.000100Z

@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.

pez 2018-08-21T07:21:29.000100Z

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.

pez 2018-08-21T07:33:02.000100Z

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?

shaunlebron 2018-08-21T16:56:51.000100Z

@henrik wow you’re right

shaunlebron 2018-08-21T16:58:28.000100Z

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

🦜 1
shaunlebron 2018-08-21T16:59:42.000100Z

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

eraserhd 2018-08-21T18:13:57.000100Z

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.

eraserhd 2018-08-21T18:14:08.000100Z

should means ideally, here.

eraserhd 2018-08-21T18:14:43.000100Z

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.

eraserhd 2018-08-21T18:15:40.000100Z

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.