Account for closing html tags during diff

[nicholaschuayunzhi]

What is the purpose of this pull request? (put "X" next to an item, remove the rest)

• [ ] Documentation update
• [X] Bug fix
• [ ] New feature
• [ ] Enhancement to an existing feature
• [ ] Other, please explain:

What is the rationale for this request?
Address the bug found in #454 where the diffing logic incorrectly identifies a diff outside a file path.

What changes did you make? (Give an overview)
The fragment that causes this is (note i've formatted it for readability)

<panel header="## Panel with src from another Markbind site header<a class='fa fa-anchor' href='#panel-with-src-from-another-markbind-site-header'></a>" 
src="/test_site
+/
-\
sub_site/index._include_.html" expanded=""></panel>

To decide if the diff \ is found in a path, it checks if the diff

1. is within a path - checking if there is a preceding src=" (yes)
2. fragment is within a html tag
   • here i check if i find a > or < first.
     • if < is found, its within a html tag - diff is in path
     • if > is found, assume not within html tag - diff is not in path (and this is incorrect for the case above)

For the last case, instead of assuming not within html tag, we look to check if the > is "closed" by a <. If so, continue searching for <.

Provide some example code that this change will affect:

Is there anything you'd like reviewers to focus on?

Testing instructions:
For code snippet in above found above in test/test_site/expected/index.html, change the path separator and check that there is no diff error reported by running npm run test.

[acjh]

Sounds odd as it sounds like we're saying one can close a tag before opening it.

Is it reasonable to assume that this is +/-1? How about hasUnmatchedClosingBracket?

[nicholaschuayunzhi]

I was thinking of a fragment like

<panel header="<a>Test</a>">

Here there are 2 > s before a <.

Maybe i will use numUnmatchedClosingBracket?

[acjh]

Ah right, thanks.

[acjh]

Remove?

[nicholaschuayunzhi]

My bad 😅

[acjh]

Maybe more intuitive to +1 before -1, and check for 0 explicitly.

if > {
  +1
} else if < {
  if 0 {
    return true
  }
  -1
}

[nicholaschuayunzhi]

I've updated the commit

[acjh]

Thanks for the fix!