Plan CommonMark-style markdown continuation toggles for quotes and block structures

[Just-Insane]

Summary

Charm's markdown input should more clearly define whether it aims to follow CommonMark-style block continuation behavior, and whether users should be able to opt into stricter or more Discord-like editor assistance for quotes, lists, and similar block structures.

This issue is for planning only.
No code changes are requested here.

What is CommonMark?

CommonMark is a standardized, testable specification for Markdown behavior. In practice, it defines how Markdown constructs such as blockquotes, lists, code blocks, emphasis, and lazy continuation lines should parse across implementations.

Relevant to Charm:

• > test is a blockquote
• consecutive > lines stay in the same blockquote
• blockquotes also allow lazy continuation lines, meaning a non-> line can still remain inside the blockquote in some cases
• lists and other block structures have similarly defined continuation and nesting rules

Why this matters

Right now, users may reasonably expect either:

• a markdown parser that behaves close to CommonMark
• a Discord-like input experience that helps keep them inside the current quote/list/code block mode
• or explicit toggles that let them choose between simpler input and more structured behavior

This is especially relevant for:

• single-line quotes
• multi-line quotes
• lazy continuation quotes such as:

  > this is a test
    test
    test

• future editor features like ASCII-to-emoji expansion or other input transforms that may also need user-facing toggles

Goals

• Decide how closely Charm should follow CommonMark for markdown block parsing
• Decide which behaviors are parser-level defaults versus editor-level assistive features
• Avoid surprising users when quote/list/code-block continuation differs from expectations formed by Discord or standard Markdown editors

Proposed plan

1. Define the target behavior surface

• Document whether Charm wants:
  • "mostly CommonMark"
  • "CommonMark with selected compatibility deviations"
  • or "Discord-inspired markdown UX layered on top of markdown parsing"

2. Split parser behavior from editor behavior

• Parser behavior:
  • how markdown is interpreted when sent, edited, and round-tripped
  • how blockquotes, lists, and lazy continuation should parse
• Editor behavior:
  • whether pressing Enter inside a quote/list/code block should continue that structure automatically
  • whether users can be "locked into" a current block until they exit it
  • whether toggles control assistive continuation separately from parser semantics

3. Add a markdown continuation preference model

• Consider user-facing toggles such as:
  • quote continuation assist
  • list continuation assist
  • code block continuation assist
  • possibly a broader "structured markdown assistance" setting
• Keep this conceptually aligned with planned toggleable input helpers like Emoji Auto-Expansion #147

4. Decide defaults carefully

• Default behavior should be predictable for new users
• Advanced users should still be able to opt into more powerful/strict continuation behavior
• Mobile and desktop composer UX may need different defaults or different ergonomics

5. Validate send/edit/round-trip consistency

• Ensure the same structure behaves consistently across:
  • composing a new message
  • editing an existing message
  • rendering timeline output
  • converting formatted HTML back to markdown-ish editor content

6. Add explicit coverage before rollout

• parser tests for blockquote/list/code-block continuation cases
• editor behavior tests for Enter/Backspace/exit behavior
• regression coverage for quote previews, edits, and markdown round-tripping

Suggested scope for follow-up implementation issues

• parser alignment with CommonMark block continuation rules
• editor assistance for continuing quote/list/code blocks on Enter
• settings/toggles for structured markdown assistance
• UX copy and settings descriptions for these toggles

Open questions

• Should Charm aim for CommonMark compatibility by default, or only offer it as an advanced mode?
• Should lazy continuation be always enabled, or behind a preference?
• Should the composer provide Discord-style block continuation ergonomics even if the parser remains markdown-first?
• Should quote/list/code-block continuation share one setting, or be broken out into separate toggles?
• How much divergence from upstream Sable is acceptable here?

Related

• Related to Emoji Auto-Expansion #147 (Emoji Auto-Expansion)