BUG: Markdown style after quote (UPDATED)
-
BUG: applying some inline markdown styles directly after a single or double quote are not interpreted as intended
Expected: "this is a quote" or 'this is a quote'
Actual: "this is a quote" or 'this is a quote'
Test Cases:"**this** is a quote"
"this is a quote"
"*this* is a quote"
"this is a quote"
"__this__ is a quote"
"this is a quote"
"_this_ is a quote"
"this is a quote"
'**this** is a quote'
'this is a quote'
'*this* is a quote'
'this is a quote'
'__this__ is a quote'
'this is a quote'
'_this_ is a quote'
'this is a quote'
-
Does _ work the same way I wonder?
"__dingleberry__"
"dingleberry"
" __dingleberry__"
" dingleberry"
yep...
edit.... italics are the same way
"_klingon_"
"klingon"
" _klingon_"
" klingon"
-
Workaround: Put your asterisks outside the quotes.
**"this is a quote"**
"this is a quote"
Oh GOD FUCKIGN DAMNIT, AUTOQUOTE_DIALECT.JS I FUCKING HATE YOU
-
But then you get bold quote marks, and I don't know if my statement is strong enough for bold quote marks....
** "tig ol bitties"**
-
That would depend on how much you like tig bitties.
Filed under: De gustibus non est disputandum
-
Couldn't resist it ....
-
Just a subtle reminder: this is the bugs category gentlemen. Mind taking it over there please? ~~~~~>
Ta.
-
Mind taking it over there please? ~~~~~>
We can write in the margins? Sweet!
Filed under: Not helping
-
Some of this is probably the intra-word emphasis protection, but it is incorrectly counting quotes as part of the word? Just a guess, @eviltrout will have to look.
-
That just seems ... strange? rendering the asterisks in unduckingbelievable seems like a bug - isn't it reasonable to assume the user wanted un[b]ducking[/b]believable? If they wanted the asterisks to be rendered, couldn't they just escape them?
Maybe I'm just confused about the point of intra-word emphasis protection? Exactly what are we being protected from? Especially since there are other, perfectly valid ways to perform the same markup?
-
Exactly what are we being protected from?
Because you don't want do_some_crazy_stuff_func to get translated to dosomecrazystufffunc.
-
Because you don't want do_some_crazy_stuff_func to get translated to do<i>some</i>crazy<i>stuff</i>func.
That seems like breaking the normal use to prevent an undesired edge case. Especially since escaping already solves the edge case.
-
Because you don't want do_some_crazy_stuff_func to get translated to dosomecrazystufffunc.
What about, say, protecting that in <pre> blocks, and not elsewhere? (Which seems to not even be a special case; Discourse appears to ignore markdown inside <pre> blocks, anyway.) If the user needs that outside a <pre> block, he/she/it can escape the punctuation.
-
-
What about, say, protecting that in <pre> blocks, and not elsewhere? (Which seems to not even be a special case; Discourse appears to ignore markdown inside <pre> blocks, anyway.) If the user needs that outside a <pre> block, he/she/it can escape the punctuation.
Markdown is always ignored inside block-level html tags (i.e.
<div>
,<p>
,<section>
,<aside>
,<pre>
). Go check out the link the the markdown tutorial
-
This has been fixed and deployed! Thanks for letting us know!
-