Markdown formatting bug when a list entry contains multiple backticked words
(1) By Stephan Beal (stephan) on 2020-11-20 11:13:35
Here's a weird markdown rendering bug for someone familiar with those bits... Note the formatting of the first word in each bullet point, each of which has identical style markup: ------ - **`uuid`**: the hash code of the blob's contents. - **`rid`**: a unique integer key for this record. This is how the blob table is mapped to other (transient) tables, but the RIDs are specific to one given copy of a repository and must not be used for cross-repository referencing. The RID is a private/internal value of no use to a user unless they're building SQL queries for use with the fossil db schema. - **`size`**: the size, in bytes, of the blob's contents, or -1 for "phantom" blobs (those which fossil knows should exist because it's seen them referenced somewhere, but for which it has not been given any content). - **`content`**: the blob's raw content bytes, with the caveat that fossil is free to store it in an "alternate representation." Specifically, the `content` field often holds a zlib-compressed delta from a previous version of the blob's content (a separate entry in the `blob` table), and an auxiliary table named `delta` maps such blobs to their previous versions, such that fossil can reconstruct the real content from them by applying the delta to its previous version (and such deltas may be chained). Thus extraction of the content from this field cannot be performed via vanilla SQL, and requires a fossil-specific function which knows how to convert any internal representations of the content to its original form. ------ Specifically: the 4th bullet point's **bold** markers are not consumed as markup, and are instead left in place. The trigger for this appears to be the subsequent backticked words in the 4th list point. If those backticks are removed, it renders as expected. Similarly, adding backticks to words in the other list entries causes them to mis-render in the same way.
(2) By Chris (crustyoz) on 2020-11-20 11:44:26 in reply to 1 [link]
It's hard to tell from the presented text but the strong tags are missing from around the word "content" but the code tags are still there so the font has changed. The subsequent backticks are rendering as code tags around the words "content", "blog" and "delta". (ctrl-U is my close friend in the Firefox browser for web development.)
(3) By Stephan Beal (stephan) on 2020-11-20 11:48:45 in reply to 2 [link]
> It's hard to tell from the presented text but the strong tags are missing from around the word "content" but the code tags are still there so the font has changed. Check the unformatted version of the post to see that the strong/bold markup is all there and, insofar as my eyes can see, intact: <https://fossil-scm.org/forum/forumpost/da5c5c4c31?raw> The bold markup around the first word of the 4th bullet point isn't being consumed by the parser, though, so the resulting HTML tags (what you'd see via ctrl-U) aren't emitted.
(4) By graham on 2020-11-20 13:04:39 in reply to 3 [link]
A similar/simpler example: **`this`** should be bold-code, and **`this`** should be as well. That is "`this` should be bold-code, and `this` should be as well" but with the two "this"s in both code and bold. It seems to be that the first bold-marker and the last bold-marker get paired up, and the bold-markers in the middle get ignored (although the code-markers _are_ spotted). Even odder, if you put the first two paragraphs together (as I did while composing), the second one alters the behaviour: A similar/simpler example: **`this`** should be bold-code, and **`this`** should be as well. That is "`this` should be bold-code, and `this` should be as well" but with the two "this"s in both code and bold.
(5) By Richard Hipp (drh) on 2020-11-20 13:14:07 in reply to 1 [link]
Simplified test case: - **`abcde`**: correctly formats as <strong><code>. - **`fghij`**: omits <strong> due to `code`.
(6) By Richard Hipp (drh) on 2020-11-20 13:21:11 in reply to 5 [link]
Just to confirm, [GitHub formats the same text correctly][1]. [1]: https://github.com/drhsqlite/fossil-mirror/wiki
(7.1) By graham on 2020-11-20 13:57:33 edited from 7.0 in reply to 5 [link]
Deleted(8) By Richard Hipp (drh) on 2020-11-20 14:42:06 in reply to 1 [link]
Apparently fixed by [check-in b4e50e9ace20f5a4](src:/info/b4e50e9ace20f5a4).
(9) By Stephan Beal (stephan) on 2020-11-20 14:53:18 in reply to 8 [link]
> Apparently fixed by check-in b4e50e9ace20f5a4. Fantastic, thank you :).