Support delimiter-based indentation in editor / live preview

Feature requests
1

The CommonMark specification states that list indentation can specified using 1) a fixed number of spaces (1 tab / four spaces) or 2) the width of the list item delimiter plus the number of spaces before the first character of the list item content (referred to as “delimiter-based indentation” moving forward).

For example:

## Fixed width indentation (1 tab / 4 spaces)

- No indent
    - First indent (4 spaces)
        - Second Indent (8 spaces)

1. No indent
    1. First indent (4 spaces)
        1. Second Indent (8 spaces)

## Delimiter-width indentation

- No indent
  - First indent (2 spaces)
    - Second Indent (4 spaces)

1. No indent
   1. First indent (3 spaces)
      1. Second Indent (6 spaces)

001. No indent
     001. First indent (5 spaces)
          001. Second Indent (10 spaces)

As of v1.0.3, Obsidian renders both indentation styles consistently in reading mode, however in live preview mode there are two inconsistencies:

  1. The inline text-indent and padding-inline-start values are different on the <div class="HyperMD-list-line"> element.
  2. A <span class="cm-indent"> element is missing when using delimiter width indention.

The result of these issues is that 1) list are rendered inconsistently in live preview based on the indention used and 2) visual indentation guides are not displayed properly when using delimiter-width indentation.

Steps to reproduce

  1. Copy/paste the CommonMark-compliant markdown above into Obsidian.

  2. Note the visual difference in indentation size and incorrect rendering of indention guides in the delimiter-based indention examples:

    CleanShot 2022-12-12 at 23.23.51@2x
    CleanShot 2022-12-12 at [email protected]952×1234 113 KB

  3. Open Obsidian’s dev tools, inspect two similar sub lists, and note two inconsistencies described above.

Expected result

I would expect lists to be rendered consistently regardless of the indentation style used.

Actual result

  • Fixed-width indention style renders properly in reading and live preview mode
  • Delimiter-based indention style only renders properly in read mode.

Environment

  • Operating system: macOS 12.6
  • Debug info:
    SYSTEM INFO:
    Obsidian version: v1.0.3
    Installer version: v1.0.3
    Operating system: Darwin Kernel Version 21.6.0: Mon Aug 22 20:20:05 PDT 2022; root:xnu-8020.140.49~2/RELEASE_ARM64_T8101 21.6.0
    Login status: not logged in
    Insider build toggle: off
    Live preview: on
    Legacy editor: off
    Base theme: adapt to system
    Community theme: none
    Snippets enabled: 7
    Restricted mode: off
    Plugins installed: 14
    Plugins enabled: 14
    1: Linter v1.8.0
    2: Style Settings v0.4.12
    3: Advanced Tables v0.18.0
    4: Natural Language Dates v0.6.1
    5: Rollover Daily Todos v1.1.3
    6: Paste image rename v1.5.0
    7: Calendar v1.5.10
    8: Periodic Notes v0.0.17
    9: Templater v1.16.0
    10: File Cleaner v0.1.5
    11: Paste URL into selection v1.7.0
    12: Note Refactor v1.7.1
    13: Sort & Permute lines v0.6.1
    14: Obsidian Git v2.12.1

RECOMMENDATIONS:
Custom theme and snippets: for cosmetic issues, please first try updating your theme and disabling your snippets. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community theme and snippets.
Community plugins: for bugs, please first try updating all your plugins to latest. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community plugins.

Additional information

Snippets are all disabled (despite what debug info above states).

Also, here is what the CommonMark authors have to say about fixed-width indention vs delimiter/content-based indentation:

The most important thing to notice is that the position of the text after the list marker determines how much indentation is needed in subsequent blocks in the list item. If the list marker takes up two spaces of indentation, and there are three spaces between the list marker and the next character other than a space or tab, then blocks must be indented five spaces in order to fall under the list item.

The strategy here is to let the width and indentation of the list marker determine the indentation necessary for blocks to fall under the list item, rather than having a fixed and arbitrary number.

This rule is superior, we claim, to any rule requiring a fixed level of indentation from the margin. The four-space rule is clear but unnatural.

6 Likes
2

I said Feature Request in the other post. So I am moving it there. Thanks for the discussion.

1 Like
3

Sounds good. Thanks, @WhiteNoise.

4

It would be very nice if that also worked in code blocks. My current problem is that I have various code snippets with different amount of spaces as indentation.

I usually try to follow the official code guidelines and the amount of spaces depends on the language. Here are some examples:

  • Web-languages like JS, HTML/CSS, SASS: 2 spaces
  • Python: 4 spaces (no tabs!)
  • C/C++, C#: Anything works but 2 or 4 spaces are usually recommended

Obviously I would like to keep using 2 spaces for web languages, but also need to use 4 spaces for Python snippets.

So if the indent lines were rendered according the actual code indentation (and not fixed to 4 spaces like it is currently), it would be super helpful.