Use diff of prev/next marker's markups instead of assuming consistent order

[bantic]

fixes #51

Using bulk edit actions (like applying/unapplying markups to a range of selected markers) could make the order of markups on contiguous markers get out of sync. Marker 1 has ['B', 'I'] and Marker 2 has ['I', 'B'], e.g. The current code that finds opened and closed markups on a marker assumes that the markups array will always be in the same order. This PR changes that to look at the difference of the two arrays rather than the slice of the current array up to the matching item in the prev/next marker's markups.

[ErisDS]

Just out of interest - has any thought been given to enforcing a consistent order for markup in mobiledoc? It's locked down/strict in other ways, it may make sense to lock this down too?

The comment here made me think of https://medium.com/medium-eng/why-contenteditable-is-terrible-122d8a40e480

[gpoitch]

Pre-mobiledoc, the parser sorted the markups so they were always in the same order

[mixonic]

When we translate markup ranges into DOM nodes, we sort them by type: A, then STRONG, then EM. We will never print a STRONG tag containing an anchor. We break it up so that the anchor contains the STRONG tag.

The internal data-structure is agnostic, but the mobiledoc renderer would currently base output on the leading tag.

For example on content like:

Hello Google

We would generate:

Marker: Hello
  opens: `b`
  closes: nothing
Marker: Google
  opens: `a`
  closes: `a`, `b`

The proposal of that ending paragraph is that we do this instead:

Marker: Hello
  opens: `b`
  closes: `b`
Marker: Google
  opens: `a`, `b`
  closes: `b`, `a`

I think this matters for medium b/c they are parsing the DOM after you edit it- We rarely look at the DOM as authoritative, and regardless we may render something different that what was parsed. For example, if you had three b tags in a row and we parsed that, the rendered mobiledoc would contain only a single b tag spanning all three text nodes.

tl;dr I'm unsure we need to enforce this for any architectural reason.

[gpoitch]

Yup, not a huge deal since dom isn't authoritative. A case for it could be if you toggle on/off a couple of markups. Visually there could be no change, but if the order of the markups in the mobiledoc changed you now have an unnecessary dirty node / post revision.