I don't think you should allow
(defn foo
[a b]
bar
baz)
this is harmful.In most editor, you can use a shortcut to pull [a b]
up.
personally, I prefer there's no intermediate state, and no warning at all.
so we can save file at any time, and never stop for reading the warning.
It's not necessary to do all things without any editor built-in command, for people who ask "why I can't pull function argument vector up by just press backspace in VIM?", we can tell him "you can achieve this with J
, it's faster and better".
I think I understand your view here. There is some precedent with allowing intermediate states depending on cursor position:
(foo [a b]|
bar)
Likewise, this new rule would do the same thing if the cursor is to the left of the open-paren:
(foo |[a b]
bar)
the warning is only intended to give plugin authors the ability to provide some affordance that the paren may be displaced in both circumstances above. (optional to show at all, but maybe these precarious parens should be highlighted yellow)
> It’s not necessary to do all things without any editor built-in command I agree. I just want to allow the most basic operations without hotkeys, as long as simple solutions are available. since this intermediate state solution seems to apply principles already found in Parinfer’s design, I’m going to see what it looks like
> so we can save file at any time you can still save a file in an intermediate state. Paren Mode will correct indentation before opening.
early version of 3.3.0 is unpublished but playable in demo: http://shaunlebron.github.io/parinfer/demo
will be looking at indentation correction after cursor movement next
The swallowing of the bar
line at the end is what I’m trying to fix now
@shaunlebron I’m having problems getting my port to work correctly.
I think the issue is that there’s now a distinction between result.x and result.inputX
And result.lineNo and result.inputLineNo.
What’s the difference between those values? When do they differ?
The previous version my port was based on didn’t have that distinction.
input coords vs output coords
right now since there are no lines added or removed, result.inputLineNo and result.lineNo will always be the same
but obviously things can change within a line—like indentation and parens—so result.inputX allows us to keep track of the original position of the current character being scanned
I use input coords when reporting errors since errors result in the original unmodified text being returned, and we don’t want to report the error position in terms of the new output text that was thrown away
I also use them to prevent problems with changes
, since subsequent change positions could be affected by previous ones.
lemme know if I can help look at the port
just published 3.3.0 with smartMode
to keep this experimental stuff out of original indent mode
the demo page defaults to smartMode, and re-exposes the other modes again for comparison: http://shaunlebron.github.io/parinfer/demo