Revise "Paredit emerges" section

[shaunlebron]

I stated things in the "Paredit emerges" section without proof, and it's been shown to not work in some cases described in #102 and #107.

I'll be revisiting assumptions. What follows is my current understanding of how to fix descriptions of expected behavior, and how to revise the rules to minimize unexpected behavior.

New Rules

1. When encountering an unmatched close paren, suspend Indent Mode.
   • unless it falls inside a Paren Trail, where by definition, its susceptible to relocation by indentation
   • is this exception truly safe?

     New Implications

If parens are balanced:

• deleting (: (potential splice)
  • splices if the matching ) is at the end of a line (or in a paren trail)
  • otherwise, follow rules as if the matching ) was inserted
• inserting (: (potential wrap)
  • wraps if not inside another expression
  • if inserted inside ( ), it is matched to the next ). follow rules as if the parent ( was just inserted
  • if inserted inside [ ] or { }, suspend
• deleting ) (potential slurp)
  • ignored (reinserted) if at a paren trail
  • otherwise, follow rules as if the matching ( was inserted
• inserting ) (potential barf)
  • ignored (removed) if at a paren trail
  • if inserted inside ( ), follow rules as if the next ) was inserted
  • if inserted inside [ ] or { }, suspend
  • if not inside another expression, suspend

If parens are imbalanced:

• if the result remains imbalanced, suspend
• otherwise, resume

[mauricioszabo]

Maybe one more case to check, suppose I have: (map (fn [c] ) changes)

If I insert (map (fn [c] {) changes), I suppose it would become (map (fn [c] {}) changes). Right now, is ignoring the close-parens and becoming: (map (fn [c] { changes})).