5 replaced http://meta.stackexchange.com/ with https://meta.stackexchange.com/
source | link

The main issue is that Markdown parser can sometimes be a bit fragile when it comes to lists and block quotes, because the boundaries aren't as well-terminated as, say, code blocks.

Barring a fix, the user-side resolution of the problem is to make the parser's job as easy as possible, which in your case would have involved the Markdown:

 - > does something exist like this for full-text indexing/searching?

 - > Has anyone ever had a similar gripe before... or am I nuts and should just keep using SQL for these situations?

which renders as

  • does something exist like this for full-text indexing/searching?

  • Has anyone ever had a similar gripe before... or am I nuts and should just keep using SQL for these situations?

Note that the > is on the same line as the -, and that the newline between the two list items is necessary for everything to turn out right.

So, what goes wrong in your case? As I alluded to in the commentsalluded to in the comments, you're actually being bitten by a blockquote-in-list bug which occurs with the second blockquote, which in turn is responsible for the bug you're actually seeing here.

While it'll take a bit more troubleshooting to see if there's a fix for the underyling issuefor the underyling issue, the trouble starts when the HTML block replacement for the second block quote inadvertently eats the closing </li></ul> from the list, leaving the parser with this (where ? is standing in for a non-printable character):

...\n\n<ul>\n<li>?H2035416125H</li>\n<li>\n\n\n?H977440878H\n\n...

Since there's no longer a closing tag for the list, the second call to HashHTMLBlocks that handles Markdown-generated blocks doesn't swap out the list as intended. This causes the input to FormParagraphs to be malformed, since even though it recursively subsitutes back in hashed blocks, it expects the top level block to be proceeded by two newlines.

Had the entire <ul> block been swapped out, this would have been fine, but because the other issue caused it not to be, the first hash marker ?H2035416125H fails the regex match and no replacement is performed.

Luckily, addressing the linked issue should cause this problem to simply go away. I've suggested some quick-fixessuggested some quick-fixes for that problem, so we'll see what balpha thinks.

The main issue is that Markdown parser can sometimes be a bit fragile when it comes to lists and block quotes, because the boundaries aren't as well-terminated as, say, code blocks.

Barring a fix, the user-side resolution of the problem is to make the parser's job as easy as possible, which in your case would have involved the Markdown:

 - > does something exist like this for full-text indexing/searching?

 - > Has anyone ever had a similar gripe before... or am I nuts and should just keep using SQL for these situations?

which renders as

  • does something exist like this for full-text indexing/searching?

  • Has anyone ever had a similar gripe before... or am I nuts and should just keep using SQL for these situations?

Note that the > is on the same line as the -, and that the newline between the two list items is necessary for everything to turn out right.

So, what goes wrong in your case? As I alluded to in the comments, you're actually being bitten by a blockquote-in-list bug which occurs with the second blockquote, which in turn is responsible for the bug you're actually seeing here.

While it'll take a bit more troubleshooting to see if there's a fix for the underyling issue, the trouble starts when the HTML block replacement for the second block quote inadvertently eats the closing </li></ul> from the list, leaving the parser with this (where ? is standing in for a non-printable character):

...\n\n<ul>\n<li>?H2035416125H</li>\n<li>\n\n\n?H977440878H\n\n...

Since there's no longer a closing tag for the list, the second call to HashHTMLBlocks that handles Markdown-generated blocks doesn't swap out the list as intended. This causes the input to FormParagraphs to be malformed, since even though it recursively subsitutes back in hashed blocks, it expects the top level block to be proceeded by two newlines.

Had the entire <ul> block been swapped out, this would have been fine, but because the other issue caused it not to be, the first hash marker ?H2035416125H fails the regex match and no replacement is performed.

Luckily, addressing the linked issue should cause this problem to simply go away. I've suggested some quick-fixes for that problem, so we'll see what balpha thinks.

The main issue is that Markdown parser can sometimes be a bit fragile when it comes to lists and block quotes, because the boundaries aren't as well-terminated as, say, code blocks.

Barring a fix, the user-side resolution of the problem is to make the parser's job as easy as possible, which in your case would have involved the Markdown:

 - > does something exist like this for full-text indexing/searching?

 - > Has anyone ever had a similar gripe before... or am I nuts and should just keep using SQL for these situations?

which renders as

  • does something exist like this for full-text indexing/searching?

  • Has anyone ever had a similar gripe before... or am I nuts and should just keep using SQL for these situations?

Note that the > is on the same line as the -, and that the newline between the two list items is necessary for everything to turn out right.

So, what goes wrong in your case? As I alluded to in the comments, you're actually being bitten by a blockquote-in-list bug which occurs with the second blockquote, which in turn is responsible for the bug you're actually seeing here.

While it'll take a bit more troubleshooting to see if there's a fix for the underyling issue, the trouble starts when the HTML block replacement for the second block quote inadvertently eats the closing </li></ul> from the list, leaving the parser with this (where ? is standing in for a non-printable character):

...\n\n<ul>\n<li>?H2035416125H</li>\n<li>\n\n\n?H977440878H\n\n...

Since there's no longer a closing tag for the list, the second call to HashHTMLBlocks that handles Markdown-generated blocks doesn't swap out the list as intended. This causes the input to FormParagraphs to be malformed, since even though it recursively subsitutes back in hashed blocks, it expects the top level block to be proceeded by two newlines.

Had the entire <ul> block been swapped out, this would have been fine, but because the other issue caused it not to be, the first hash marker ?H2035416125H fails the regex match and no replacement is performed.

Luckily, addressing the linked issue should cause this problem to simply go away. I've suggested some quick-fixes for that problem, so we'll see what balpha thinks.

4 Migration of MSO links to MSE links
source | link

The main issue is that Markdown parser can sometimes be a bit fragile when it comes to lists and block quotes, because the boundaries aren't as well-terminated as, say, code blocks.

Barring a fix, the user-side resolution of the problem is to make the parser's job as easy as possible, which in your case would have involved the Markdown:

 - > does something exist like this for full-text indexing/searching?

 - > Has anyone ever had a similar gripe before... or am I nuts and should just keep using SQL for these situations?

which renders as

  • does something exist like this for full-text indexing/searching?

  • Has anyone ever had a similar gripe before... or am I nuts and should just keep using SQL for these situations?

Note that the > is on the same line as the -, and that the newline between the two list items is necessary for everything to turn out right.

So, what goes wrong in your case? As I alluded to in the commentsalluded to in the comments, you're actually being bitten by a blockquote-in-list bug which occurs with the second blockquote, which in turn is responsible for the bug you're actually seeing here.

While it'll take a bit more troubleshooting to see if there's a fix for the underyling issuefor the underyling issue, the trouble starts when the HTML block replacement for the second block quote inadvertently eats the closing </li></ul> from the list, leaving the parser with this (where ? is standing in for a non-printable character):

...\n\n<ul>\n<li>?H2035416125H</li>\n<li>\n\n\n?H977440878H\n\n...

Since there's no longer a closing tag for the list, the second call to HashHTMLBlocks that handles Markdown-generated blocks doesn't swap out the list as intended. This causes the input to FormParagraphs to be malformed, since even though it recursively subsitutes back in hashed blocks, it expects the top level block to be proceeded by two newlines.

Had the entire <ul> block been swapped out, this would have been fine, but because the other issue caused it not to be, the first hash marker ?H2035416125H fails the regex match and no replacement is performed.

Luckily, addressing the linked issue should cause this problem to simply go away. I've suggested some quick-fixessuggested some quick-fixes for that problem, so we'll see what balpha thinks.

The main issue is that Markdown parser can sometimes be a bit fragile when it comes to lists and block quotes, because the boundaries aren't as well-terminated as, say, code blocks.

Barring a fix, the user-side resolution of the problem is to make the parser's job as easy as possible, which in your case would have involved the Markdown:

 - > does something exist like this for full-text indexing/searching?

 - > Has anyone ever had a similar gripe before... or am I nuts and should just keep using SQL for these situations?

which renders as

  • does something exist like this for full-text indexing/searching?

  • Has anyone ever had a similar gripe before... or am I nuts and should just keep using SQL for these situations?

Note that the > is on the same line as the -, and that the newline between the two list items is necessary for everything to turn out right.

So, what goes wrong in your case? As I alluded to in the comments, you're actually being bitten by a blockquote-in-list bug which occurs with the second blockquote, which in turn is responsible for the bug you're actually seeing here.

While it'll take a bit more troubleshooting to see if there's a fix for the underyling issue, the trouble starts when the HTML block replacement for the second block quote inadvertently eats the closing </li></ul> from the list, leaving the parser with this (where ? is standing in for a non-printable character):

...\n\n<ul>\n<li>?H2035416125H</li>\n<li>\n\n\n?H977440878H\n\n...

Since there's no longer a closing tag for the list, the second call to HashHTMLBlocks that handles Markdown-generated blocks doesn't swap out the list as intended. This causes the input to FormParagraphs to be malformed, since even though it recursively subsitutes back in hashed blocks, it expects the top level block to be proceeded by two newlines.

Had the entire <ul> block been swapped out, this would have been fine, but because the other issue caused it not to be, the first hash marker ?H2035416125H fails the regex match and no replacement is performed.

Luckily, addressing the linked issue should cause this problem to simply go away. I've suggested some quick-fixes for that problem, so we'll see what balpha thinks.

The main issue is that Markdown parser can sometimes be a bit fragile when it comes to lists and block quotes, because the boundaries aren't as well-terminated as, say, code blocks.

Barring a fix, the user-side resolution of the problem is to make the parser's job as easy as possible, which in your case would have involved the Markdown:

 - > does something exist like this for full-text indexing/searching?

 - > Has anyone ever had a similar gripe before... or am I nuts and should just keep using SQL for these situations?

which renders as

  • does something exist like this for full-text indexing/searching?

  • Has anyone ever had a similar gripe before... or am I nuts and should just keep using SQL for these situations?

Note that the > is on the same line as the -, and that the newline between the two list items is necessary for everything to turn out right.

So, what goes wrong in your case? As I alluded to in the comments, you're actually being bitten by a blockquote-in-list bug which occurs with the second blockquote, which in turn is responsible for the bug you're actually seeing here.

While it'll take a bit more troubleshooting to see if there's a fix for the underyling issue, the trouble starts when the HTML block replacement for the second block quote inadvertently eats the closing </li></ul> from the list, leaving the parser with this (where ? is standing in for a non-printable character):

...\n\n<ul>\n<li>?H2035416125H</li>\n<li>\n\n\n?H977440878H\n\n...

Since there's no longer a closing tag for the list, the second call to HashHTMLBlocks that handles Markdown-generated blocks doesn't swap out the list as intended. This causes the input to FormParagraphs to be malformed, since even though it recursively subsitutes back in hashed blocks, it expects the top level block to be proceeded by two newlines.

Had the entire <ul> block been swapped out, this would have been fine, but because the other issue caused it not to be, the first hash marker ?H2035416125H fails the regex match and no replacement is performed.

Luckily, addressing the linked issue should cause this problem to simply go away. I've suggested some quick-fixes for that problem, so we'll see what balpha thinks.

3 added 134 characters in body
source | link

The main issue is that Markdown parser can sometimes be a bit fragile when it comes to lists and block quotes, because the boundaries aren't as well-terminated as, say, code blocks.

Barring a fix, the user-side resolution of the problem is to make the parser's job as easy as possible, which in your case would have involved the Markdown:

 - > does something exist like this for full-text indexing/searching?

 - > Has anyone ever had a similar gripe before... or am I nuts and should just keep using SQL for these situations?

which renders as

  • does something exist like this for full-text indexing/searching?

  • Has anyone ever had a similar gripe before... or am I nuts and should just keep using SQL for these situations?

Note that the > is on the same line as the -, and that the newline between the two list items is necessary for everything to turn out right.

So, what goes wrong in your case? As I alluded to in the comments, you're actually being bitten by a blockquote-in-list bug which occurs with the second blockquote, which in turn is responsible for the bug you're actually seeing here.

While it'll take a bit more troubleshooting to see if there's a fix for the underyling issue, the trouble starts when the HTML block replacement for the second block quote inadvertently eats the closing </li></ul> from the list, leaving the parser with this (where ? is standing in for a non-printable character):

...\n\n<ul>\n<li>?H2035416125H</li>\n<li>\n\n\n?H977440878H\n\n...

Since there's no longer a closing tag for the list, the second call to HashHTMLBlocks that handles Markdown-generated blocks doesn't swap out the list as intended. This causes the input to FormParagraphs to be malformed, since even though it recursively subsitutes back in hashed blocks, it expects the top level block to be proceeded by two newlines.

Had the entire <ul> block been swapped out, this would have been fine, but because the other issue caused it not to be, the first hash marker ?H2035416125H fails the regex match and no replacement is performed.

Luckily, addressing the linked issue should cause this problem to simply go away. I'll take a look atI've suggested some quick-fixes for that later andproblem, so we'll see if I can suggest a solutionwhat balpha thinks.

The main issue is that Markdown parser can sometimes be a bit fragile when it comes to lists and block quotes, because the boundaries aren't as well-terminated as, say, code blocks.

Barring a fix, the user-side resolution of the problem is to make the parser's job as easy as possible, which in your case would have involved the Markdown:

 - > does something exist like this for full-text indexing/searching?

 - > Has anyone ever had a similar gripe before... or am I nuts and should just keep using SQL for these situations?

which renders as

  • does something exist like this for full-text indexing/searching?

  • Has anyone ever had a similar gripe before... or am I nuts and should just keep using SQL for these situations?

Note that the > is on the same line as the -, and that the newline between the two list items is necessary for everything to turn out right.

So, what goes wrong in your case? As I alluded to in the comments, you're actually being bitten by a blockquote-in-list bug which occurs with the second blockquote, which in turn is responsible for the bug you're actually seeing here.

While it'll take a bit more troubleshooting to see if there's a fix for the underyling issue, the trouble starts when the HTML block replacement for the second block quote inadvertently eats the closing </li></ul> from the list, leaving the parser with this (where ? is standing in for a non-printable character):

...\n\n<ul>\n<li>?H2035416125H</li>\n<li>\n\n\n?H977440878H\n\n...

Since there's no longer a closing tag for the list, the second call to HashHTMLBlocks that handles Markdown-generated blocks doesn't swap out the list as intended. This causes the input to FormParagraphs to be malformed, since even though it recursively subsitutes back in hashed blocks, it expects the top level block to be proceeded by two newlines.

Had the entire <ul> block been swapped out, this would have been fine, but because the other issue caused it not to be, the first hash marker ?H2035416125H fails the regex match and no replacement is performed.

Luckily, addressing the linked issue should cause this problem to simply go away. I'll take a look at that later and see if I can suggest a solution.

The main issue is that Markdown parser can sometimes be a bit fragile when it comes to lists and block quotes, because the boundaries aren't as well-terminated as, say, code blocks.

Barring a fix, the user-side resolution of the problem is to make the parser's job as easy as possible, which in your case would have involved the Markdown:

 - > does something exist like this for full-text indexing/searching?

 - > Has anyone ever had a similar gripe before... or am I nuts and should just keep using SQL for these situations?

which renders as

  • does something exist like this for full-text indexing/searching?

  • Has anyone ever had a similar gripe before... or am I nuts and should just keep using SQL for these situations?

Note that the > is on the same line as the -, and that the newline between the two list items is necessary for everything to turn out right.

So, what goes wrong in your case? As I alluded to in the comments, you're actually being bitten by a blockquote-in-list bug which occurs with the second blockquote, which in turn is responsible for the bug you're actually seeing here.

While it'll take a bit more troubleshooting to see if there's a fix for the underyling issue, the trouble starts when the HTML block replacement for the second block quote inadvertently eats the closing </li></ul> from the list, leaving the parser with this (where ? is standing in for a non-printable character):

...\n\n<ul>\n<li>?H2035416125H</li>\n<li>\n\n\n?H977440878H\n\n...

Since there's no longer a closing tag for the list, the second call to HashHTMLBlocks that handles Markdown-generated blocks doesn't swap out the list as intended. This causes the input to FormParagraphs to be malformed, since even though it recursively subsitutes back in hashed blocks, it expects the top level block to be proceeded by two newlines.

Had the entire <ul> block been swapped out, this would have been fine, but because the other issue caused it not to be, the first hash marker ?H2035416125H fails the regex match and no replacement is performed.

Luckily, addressing the linked issue should cause this problem to simply go away. I've suggested some quick-fixes for that problem, so we'll see what balpha thinks.

2 added 1279 characters in body
source | link
1
source | link