**Hello** World_**Hello** World_
***Hello** World*
The actual result is correct. It’s the reading mode that is wrong.
Hmm, that’s true. Ok, well - still a bug I guess?
Looks like an upstream (codemirror) thing. So I guess it’s a wontfix.
Well, if it “works” by using underscores for italics, how about just having Obsidian use that instead of *s?
This is not a code mirror problem. The editor is looking fine in your screenshot. The problem is in reading mode.
I’m not sure that Obsidian is alone is previewing emphasis incorrectly where the pairing is split in this way. See e.g. Markdown Live Preview.
I can’t find any reference but perhaps the markdown spec is unclear on what to do with these cases.
But it’s a simple enough workaround as your own example made clear. You manually insert underscores in place of single asterisks for the italics.
The GitHub link is, I think, a red herring since it refers to a different case, where a space intervenes before a closing bold (or italic).
it happens only when the bold and italic is at the end of the sentence
RECOMMENDATIONS:
none
thanks
I can’t tell if this is bug report is marked as only being relevant to reading mode, but I am observing the same in live preview in Obsidian 1.2.1
Maybe relevant:
It seems that the bold class styling is simply being overridden. Maybe simply removing font-weight: var(--italic-weight); would be a fix?
I am happy to make a new bug report that specifically targets live preview if this would be preferred
Composing overlapping Markdown font directives doesn’t work, resulting in the following (mis)render.
Under Windows 10, notably. v0.8.15.
uhm… not sure this is generally agreead upon behaviour.
I am gonna move this to feature requests
https://babelmark.github.io/?text=***cat**+dog*
I’m not sure which programs would interpret this combination as desired
Using underlines and asterisks ought to work
I would find that a more acceptable answer (in general) if the default italic that you get when hitting Control-I wasn’t the single asterisk but the single underline.
By default, it’s choosing a mechanism that is overloaded. One of these behaviors probably needs to change in order to avoid the conflict arising from natural use of the product.
It would be even better if markdown didn’t have syntax clashes.
Whichever approach is used, shouldn’t the editor and the preview be consistent? In the example given, it looks like the editor applies italics whereas the preview does not.
iirc the editor and the preview are based on different engines, so potential for discrepancies exists.
That will disappear with wysiwyg
I feel a bit torn about this. I’ll move it back to bug reports.
