Reading mode: Bug when italics and bold are applied to a text that has a space

Steps to reproduce

  1. Start with this text in a note: **Hello** World
  2. Select All
  3. Hit the keyboard shortcut for Italics (e.g. ⌘I)

Expected result

_**Hello** World_

Actual result

***Hello** World*



  • Operating system: macOS 12.0.1
  • Obsidian version: 0.13.0

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).

This gif should be self-explanatory

Canvas Rendering bug

it happens only when the bold and italic is at the end of the sentence


  • Operating system:
  • Debug info:
    Obsidian version: v1.1.12
    Installer version: v1.1.9
    Operating system: Windows 10 Pro 10.0.19044
    Login status: logged in
    Catalyst license: insider
    Insider build toggle: on
    Live preview: on
    Legacy editor: off
    Base theme: dark
    Community theme: none
    Snippets enabled: 0
    Restricted mode: on


Additional information



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.

1 Like

Under Windows 10, notably. v0.8.15.

uhm… not sure this is generally agreead upon behaviour.

I am gonna move this to feature requests***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.

1 Like

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.

1 Like