bracket finding now retry with different syntax-scope area #644

Merged
merged 6 commits into from Jan 5, 2017

Projects

None yet

1 participant

@t9md
Owner
t9md commented Jan 4, 2017 edited

DONE:

I know this is still Not perfect. But will stop now to tackle this further.

What was changed?

  • BracketFinder( PairFinder of {, }, (, ), [, ], <, >) now care about syntax-scope when finding pair char.

  • Finding order is always:

    • First, find close char in forwarding direction.
    • Then, find open char in backward direction.
  • Strategy

    • When we find close char: Try to find from same scope at cursor(when cursor is in comment, we search in comment scope)
    • When we find open char: Opening char must match scope with closing char's scope
      • So } in comment and { in normal code area never be matched
    • If we can't find matching pair range then BracketFinder retry to finding close and open in different scope
      • If cursor was at normalCodeArea(not in comment/string/inner-double-quote), then retry with non-normalCodeArea
      • If cursor was at non-normalCodeArea then retry with normalCodeArea
  • I noticed some corner case the matching area still not intuitive.

  • But this is never be perfect, and as long as I checked manually in different wired text, I can't find any regression introduced by this smarter-behavior.

  • I know smartness vs intuitiveness(or explicitness) problem, smartness tend to break user's expectation.

  • But for this addition, I feel it reduced chance to break user's expectation, so will merge it.

@t9md t9md merged commit 49957c3 into master Jan 5, 2017

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment