[markdown-preview] Fix failure to serialize to HTML…

[savetheclocktower]

…when the document contains certain kinds of code blocks.

This fixes #1044.

When we serialize the Markdown preview to HTML, we want to incorporate the syntax highlighting — so we yoink it out of the editor instead of just taking the PRE element as-is.

In order to do that safely, we have to wait until an editor component is ready to be read from — we don't want to try to read it while it's in the middle of an update. So we politely ask to be notified the next time the component is done updating.

But what if the component isn't in the middle of an update? In theory, getNextUpdatePromise() should either (a) schedule an update just to create a promise that will soon be fulfilled, or (b) return Promise.resolve() so that the promise is immediately fulfilled. (Offhand I don't remember which one is supposed to happen.) But when the editor uses a TextMate grammar, neither thing happens. So those promises don't get fulfilled and the command just never completes.

This is a complicated thing to dig into. As an alternative, I threw in a fallback code path that impatiently plows ahead if the update doesn't happen within 500ms. Going that long without an update makes it pretty unlikely that we'd catch the editor in the middle of an update if we proceeded with reading its contents.

While testing this fix, I found a different issue: some styles introduced in #984 (and meant to apply only in the preview pane) were being copied during HTML generation and were having unwanted side effects in the resulting markup. Namely: if there were N consecutive PRE elements (with no elements in between), all PREs after the first were hidden. I fixed this by adding a data- attribute to the PRE elements in generated HTML so we could tell them apart from the ones in the preview pane.

Testing

To replicate this, you must have at least one plain-text code block; or else one code block that will use a TextMate grammar, like Less or CoffeeScript. (Plain text in Pulsar still uses a TextMate style “null” grammar and is therefore susceptible to this bug.)

First, create some Markdown like…

# Test

```
testing
```

Then either invoke the Markdown Preview: Copy HTML command… or show the preview pane, right-click on it, and choose Save as HTML.

On master and in the latest release (and many releases before that), neither action would complete. On this PR branch, both actions should generate HTML.

[savetheclocktower]

Somewhat relatedly:

It's arguably a bit weird that we try to incorporate the syntax highlighting for both “Copy HTML” and “Save as HTML.” I’m more easily persuaded that it's correct to retain syntax highlighting for the latter command; for “Copy HTML,” it's not obvious what the user's intent is, or whether they even want the highlighting to be preserved.

The user on Discord who reminded me about this bug said that they try to avoid assigning a language to a code block — even though, in most cases, that acts as a workaround for this bug! — because then their pre elements are filled with a whole bunch of tag soup.

At the very least, I think we should introduce config options for each of these commands that govern whether they retain or ignore syntax highlighting for HTML generation.