Fork me on GitHub

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


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.


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?


@henrik wow you’re right


(foo \Tbar
would expand to:
(foo bar

parrot 4

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


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.


should means ideally, here.


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.


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.