Support delimiter-based indentation guides in editor / live preview

[jhildenbiddle]

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:

   

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.

[WhiteNoise]

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

[jhildenbiddle]

Sounds good. Thanks, @WhiteNoise.

[midvok]

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.

[makaze]

Many formatters (incuding deno) enforce 2-space indent by default. Respecting Obsidian’s formats requires turning off auto-format for vault directories or changing the global settings. Obsidian should respect rather than have an opinion about the user’s choices.

[jjspace]

I’ve been getting pretty frustrated with this recently too. 2 spaces is natural for me coming from code editors and is the default for many other MD based applications. The extra annoying part is that 2 or 3 spaces works perfectly fine in reader mode but not editor. I’d really like to have good looking indent guides for all levels so it’s easier to visually see them but this issue is breaking that.
Forcing 4 spaces/1 tab may be portable to other systems but it’s not portable from other systems that support CommonMark which does not enforce 4 spaces / 1 tab.

[WhiteNoise]

I think we are going off topic here. This FR is about variable size number of spaces (depending on the delimiter size) and indentation guides.

The last two posts are about fixed size number of spaces. You should follow this thread instead and also be aware that sometimes a fixed number of spaces WILL NOT indent because the markdown spec actually uses a variable number of spaces as outlined in this thread.

And again, the problem is with indentation guides in live preview. If they look broken you can disable it in the settings.

[JonSchneider]

Aha! Turning off Options > Editor > “Show indentation guides” is the workaround that I was looking for to not have my bulleted list with 3 or more indent levels look broken when in View > “Source mode”. Thank you!

[Seren]

Turning off the indentation guides fixed the broken Editing view of 2-space multiply-indented lists. Thanks @JonSchneider!

It really would be nice to have the guides working properly in Editing mode though. Consider this a vote for this FR.