I’d love to see Lettera add a setting to control how it indents nested lists when editing Markdown. For example:
2 spaces
4 spaces
Tabs
Current behavior
The main reason is interoperability. Many of us edit the same Markdown files across multiple editors (especially Obsidian), and each editor has its own indentation convention. While CommonMark permits multiple valid indentation styles, it’s much nicer if an editor consistently uses the style the user prefers rather than rewriting whitespace unexpectedly. This also helps avoid unnecessary diffs in version control.
For example, many people—including me—edit the same Markdown files in both Lettera and Obsidian. When the two editors use different indentation styles, opening and saving a note can introduce whitespace-only changes, making diffs noisier and version history harder to read. An optional indentation preference would avoid this while preserving Lettera’s excellent rendering.
While looking into this, I also noticed what may be a bug or unexpected behavior.
Lettera version: 1.0.0 (4091)
macOS version: Tahoe 26.5.1 (25F80)
Feature used: Numbered lists
What happened: The first nesting level used three spaces, while the second appeared to use space + tab + space.
What I expected: A consistent indentation style (e.g. 2 spaces, 4 spaces, or tabs).
As I understand it, the generated Markdown is still valid CommonMark. My request isn’t about standards compliance; it’s about producing predictable Markdown that works well across editors and minimizes unnecessary formatting changes.
Would it be possible to add an optional indentation preference while keeping Lettera’s rendering unchanged?
Lettera (and Bear) uses full CommonMark-compliant parsing for indentation. And when editing, it uses spaces for indentation, as many as needed to line up things visually. In most cases, this is two spaces. For ordered lists, two spaces are sometimes not enough. If it inserts a tab it is a bug and we would need a more detailed description so we can reproduce it.
For Lettera, it could make sense to support alternative indentation schemes. Unfortunately, a fixed width (2 or 4 spaces, or tag), is strictly not fully compatible with CommonMark. But as you say, other tools use them anyway, and we could adapt to it.
I know Bear decided a few years ago to lean into CommonMark. Ultimately, beyond what the CommonMark parser accepts as valid input (2 or 4), I think what would solve the problem that many like myself had is if Bear could have the ability to change its underlying output as it regards the number of spaces at different list levels. I think there’s some disconnect between how we users asking for this understand Bear to be acting as the mediator of the raw Markdown and the parsed output, and what you’re hearing as the request, as you do properly understand the stack of parser vs editor when you guys think about this conceptually as developers. And it’s possible this is a much harder ask than any of us as users realize.
At the end of the day, I just want to be able to copy text from Bear into any of the many different MD apps I use that expect four spaces for an extra layer of nesting without having to run a regular expression on it first. I miss when that was the case, and right now Bear is the only app that I use that I have to do any weird Markdown translating (from) to any other app for the parts of syntax I use (it helps not doing much with images). It does not matter to me what Bear accepts as valid Markdown in this regard (e.g. two spaces indents), I just want to be able to have what I write be four-space indents when I’m taking it out of Bear (or now in the case of Lettera, what’s getting saved to disk).
Unfortunately, the indentation rules for CommonMark are not like that. For example, an ordered list requires at least three spaces (or more if there are many items). Four spaces or a tab are in most situations enough, but not always.
Bear will most likely continue to use the current indentation scheme (to align things nicely visually, as that is what CommonMark tries to provide). We could potentially support copying in different formats, but that is right now secondary to making Lettera compatible with different indentation forms. The good news is that we have our own parser and normalization code, so we are not bound by external dependencies, and we have some ideas on how to do it.