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.
I missed this report and created a new topic with the same issue.
I also echo the request for option to have the indentation either:
Use current default behavior
Allow user to select to use fix number of spaces
Allow user to select to use tabs
I also prefer consistency between indentation (I’ve been using 4 spaces for each indentation). I’ve mostly using Simplenote, Obsidian and vim to edit my Markdown notes. I don’t have problems with my current method when I transfer/copy and paste notes between these 3 programs. For me, its more about providing a consistent indentation and not about the different flavors of markdown.
Yesterday I opened a md file edited by Lettera and found its different default indentation depending on unordered lists vs numbered lists, making my note look misaligned when using a plain text editor (vim). I ended up in vim manually aligning the notes. Its maybe a me thing, but I occasionally mix unordered list and numbered list depending on topic.
I’m sorry, I’m confused by this. This seems to make clear that 2 is insufficient?
At the end of the day, Bear still changes the number of spaces in input created outside of it after paste to reduce the number of spaces to two (per level). Workflows that I got used to before the editor rewrite have involved me running regular expressions on Bear’s output ever since putting more spaces in.
I realize the Markdown spec world is a mess, I really just wish for old behavior back. Maybe I use more indented lists than most people, but I’m actually shocked at how many of my other tools don’t play well with two spaces based on how little chatter there is on this (and the odds that others must be running into the same).
I’m guessing may be referring to ordered (numbered) vs unordered (dash) lists. Maybe some of these markdown apps are aggressive in how they control ordered lists.
For kicks, I tried creating a numbered lists while skipping numbers with single, double, triple and more digits in plain text. Lettera will render these numbers correctly, but the alignment for single digits seems to be “right justified” with 2 digits. The rest of the 2 or more digits are left aligned. The behavior between different markdown apps (Obsidian and Lettera) when I edit any of the numbered digits I skipped will renumber these numbers.. Unsure how I feel about this. Granted, this isn’t how I normally work so its more for testing. Disappointly in Lettera, as soon as edit any items in this list, it changes the spacing to what it uses instead of respecting my 4 spaces.
I guess in the end, its 2 separate but related issues of how a markdown app renders visually vs actually changing the plain text. I personally prefer leaving the plain text (such as don’t change the spacing.
I guess I’m also surprised with this behavior as well. I’ve been using markdown for years (mostly in SimpleNote, Obsidian and plain text editor..mostly vim, and copying and pasting between apps) and never ran into markdown indentation issues until Lettera. Either way, learned something new! Hopefully an indentation option can be added.
