Support Indentation Guides for all tab sizes (2 and 3 spaces)

Use case or problem

Indentation Guides currently only support a Tab Size of 4 in Source mode and Live Preview. For other tab sizes, they do not appear. Reading view does support other tab sizes.

Proposed solution

Allow Indentation Guides to appear in Source mode and Live Preview when other values are set for Settings > Editor > Tab size.


I would clarify that this an issue with indentation in general, not how indentation guides are rendered when Edit > Show indention guides is enabled in the preferences.

Consider the following markdown:

Bullet and task lists use 2 spaces for indentation:

- Level 1
  - Level 2 (indent = 2 spaces)
    - Level 3 (indent = 4 spaces)

- [ ] Level 1
  - [ ] Level 2 (indent = 2 spaces)
    - [ ] Level 3 (indent = 4 spaces)

Ordered lists use 3 spaces for indentation:

1. Level 1
   2. Level 2 (indent = 3 spaces)
      3. Level 3 (indent = 6 spaces)

This is how I prefer to format markdown by hand and how most editors and linters I’ve used format markdown out-of-the-box (e.g. Typora, VSCode, markdown-lint, etc.):

The advantage of using this style of indention is alignment is maintained when viewing the markdown source and (most importantly) markdown adhering to this style is much more portable to/from other environments compared to Obsidian markdown which requires everything to be indented using four spaces (or 1 tab) to render properly.

Here is how the above markdown renders in Obsidian 1.0.3 using the default theme:

Not great.

In order to have the markdown render as expected, all indentions would need to be switched to 4 spaces (or 1 tab):

All lists using 4 spaces for indention:

- Level 1
    - Level 2 (indent = 4 spaces)
        - Level 3 (indent = 8 spaces)

- [ ] Level 1
    - [ ] Level 2 (indent = 4 spaces)
        - [ ] Level 3 (indent = 8 spaces)

1. Level 1
    2. Level 2 (indent = 4 spaces)
        3. Level 3 (indent = 8 spaces)

Renders (correctly) as:

Much better… for users who only care about working in Obsidian. For those of us who work in other environments or collaborate with others who may not use Obsidian, this “fixed for Obsidian” four-space-indentation-only requirement breaks one of Markdown’s biggest features: portability.

FWIW, Typora handles this very well. It allows multiple indentation styles to exist within the same document and they all render properly / identically.

The 1 tab/4 spaces is portable. It adheres to the commonmark standard for all list types.
Now you may not find it pleasing to see in plain text mode, but it is portable.

Maybe you should open a FR asking for context aware indentation with spaces and also FR asking to readjust the indentation if you switch from bullet list to checklist and so on. On top of this, there maybe user who really don’t want variable length indentation.

A fair point.

To clarify, I’m referring to delimiter width-based indentation which is also part of the CommonMark standard. The “2 and 3 spaces” portion of the title is really just describing a typical scenario (2 spaces for an unordered or tasks list, 3 spaces for an ordered list) which could cause some confusion.

Regarding portability, markdown formatted using 1 tab/4 space is portable to/from Obsidian and other CommonMark-compliant environments, but Obsidian currently does not render delimiter width-based indentation properly which (IMHO) means markdown coming in to Obsidian from other environments is less portable.

To help demonstrate the issue, copy/paste the markdown below in to other CommonMark-compliant environments like the commonmark.js dingus, babelmark, VSCode, GitHub, Typora, etc. and notice how they all render properly, then copy/paste it into Obsidian and notice how only the 4-space indentation markdown is rendered properly.

Regardless of whether Obsidian’s inability to render this markdown properly is filed as a bug or a feature request, the bottom line that the issue exists for Obsidian but not the other markdown environments listed above.

## Delimiter-width indentation

### Unordered Lists

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

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

### Ordered Lists

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)

## 4 spaces indentation

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

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

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

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

This is your assumption. People may want fixed length indentation nevertheless in markdown or in code blocks.

This is the problem of this topic, indentation lines are fixed at 4 spaces. But aside from the indentation lines the editor and the reader parsers work, assuming the appropriate number of spaces according the spec (we are aware of some corner case not handled well by the reader, but it will be fixed at some point when we update the library)

This is true for reading mode, but it is not true for live-preview mode. The markup under the hood is almost identical when indenting using fixed-width (1 tab/4 spaces) compared to delimiter-based indentation except for:

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

Fixing (1) would address the issue I am referring to which is inconsistently rendering lists using delimiter-based indention as defined in the CommonMark specification (fixed-width indention is one way but not the only way to indent content defined by the spec).

Fixing (2) would address the missing indentation guide issue for people like me who read the “2 and 3 spaces” portion of this feature request’s title to mean delimiter-based indention.

For that it’s worth, here’s 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.

I’m happy to create a separate bug report regarding the rendering inconsistency.

Sure, you can open a Feature Request to support delimiter-based indention in the editor.

Referenced FR: