variable indentation levels / hierarchy in lists

[JP LeBreton]

I've been writing gemini text for about a month now, and as a former
plaintext stickler I've found it easy, sensible, and pleasant. The
spec avoids the "formatting traps" of many rich text formats that
tempt authors into fussing with cosmetic issues.

The one thing I'm really missing is the ability to have hierarchical
lists that display in an indented form, like so:

* Top-level item 1
** Subsection 1A
** Subsection 1B
*** Sub-subsection i
*** Sub-subsection ii
** Subsection 1C
* Top-level item 2
** Subsection 2A
* Top-level item 3

I think hierarchies like this are a uniquely useful way of structuring
ideas, and adding something like this - which, to be clear, clients
would be as free to ignore as any of the other optional line types -
would expand the kinds of information that people would be able to
usefully write on Gemini. I'm curious as to how many people agree.

Markdown seems to use whitespace to indicate indent level, but I know
people have strong feelings about significant whitespace. I don't feel
too strongly about the syntax; I'm not as experienced with shaping
specifications as many folks here and defer to that expertise.

Rendering these properly would add some complexity to client logic,
but in thinking through how I'd implement one it doesn't seem like
it'd be a deal-breaker; clients already have to use some state-like
concept to correctly handle preformatted blocks, lists etc.

I've read a significant portion of the archives of this mailing list
to get a feel for how spec-related discussions have gone thus far, and
so I could make my case here persuasively. If this has already been
hashed out and I missed it, I apologize. I also totally understand if
line type complexity is something where folks feel they must "hold the
line" against further complexity. I'm speaking mostly as someone who's
enjoyed exploring Gemini space and building a small presence here.
Thanks for your time!

- JP
gemini://gem.vectorpoem.com