Closed shaunlebron closed 8 years ago
fixing this would break barf feature seen here:
not sure how to fix this. I think i'll define this as a problem w/ no solution in Indent Mode.
Problem statement: Inserting a (
is only safe when the next )
is inferred.
This is the result of an assumption that was made without much thought:
Any unmatched close-parens are removed. This makes the next transformations simpler and more predictable.
More examples of unexpected behaviors related to this issue:
)
at (foo (bar| baz) qux)
(foo (bar) baz qux)
(assuming the advertised behavior of auto-barf)(foo (bar) baz) qux
(
at (foo (bar |baz) qux)
(foo (bar (baz)) qux)
(foo (bar (baz) qux))
Proposing a new rule to cut down on surprise while preserving benefits:
Examples:
Rather than removing the unmatched close-paren here, we simply highlight what is preventing parinfer from proceeding.
(foo [|bar) baz
^ highlight unmatched
User then completes the operation since it cannot be inferred.
(foo [bar]) baz
started work here: https://github.com/shaunlebron/parinfer/tree/unmatched-close-paren
satisfied with this. in 1.9.0-beta, not released yet
thanks to @snoe for bringing this up.
Currently, unmatched close-parens are removed indiscriminately. This is a problem for the following case
because Indent Mode will turn it into:
The obvious solution is to match the
)
with the(
further back, then to close all open-parens between them, so that we have this:But this new behavior would imply that typing an unmatched
)
belowwould result in:
I will look at how this affects Indent Mode.