variable indentation levels / hierarchy in lists

1. JP LeBreton (jplebreton (a) gmail.com)

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:



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

Link to individual message.

2. Alex // nytpu (alex (a) nytpu.com)

I would say that you can actually just use variable depth lists anyways,
like this:


  * item 2

  * item 4
    * etc.

But the main thing I'd be worried about is clients that do render
regular bullets with fancy bullets wouldn't work properly. I threw
together a test document with different styles here:
gemini://nytpu.com/experiments/deep-list.gmi

Apparently Lagrange strips out all leading whitespace, Kristall indents
first-level items, making second-level look further left, and Bombadillo
(and presumably other tui clients) render it properly.

Screenshots of all the clients I tested on: https://imgur.com/a/A7CvGC6

I am not speaking in favor of any change or non-change to the spec. I
just did this to test how it would be rendered if you decided to try to
do it anyways (I'd heed "Authors should not expect to exercise any
control over the precise rendering of their text lines").

I actually would appreciate multi-level lists up to three levels deep,
indented with one space, or with multiple stars.


 * level 2
  * level 3
OR


It maintains the "check only the first three characters" limit, is
non-breaking, and is not required for clients to implement. I am merely
suggesting it as a *possible* change, but I am unsure whether I even
should mention it or not because I'm generally in the "don't change the
spec" crowd, but I feel I should at least put it forward for discussion.

-- 
Alex // nytpu
alex at nytpu.com
GPG Key: https://www.nytpu.com/files/pubkey.asc
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://useplaintext.email/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201202/bd75
045b/attachment.sig>

Link to individual message.

3. Gary Johnson (lambdatronic (a) disroot.org)


> I actually would appreciate multi-level lists up to three levels deep,
> indented with one space, or with multiple stars.
>
> * level 1
>  * level 2
>   * level 3
> OR
> * level 1
> ** level 2
> *** level 3
>
> It maintains the "check only the first three characters" limit, is
> non-breaking, and is not required for clients to implement. I am merely
> suggesting it as a *possible* change, but I am unsure whether I even
> should mention it or not because I'm generally in the "don't change the
> spec" crowd, but I feel I should at least put it forward for discussion.

I concur for all the reasons listed here. I'd prefer the multiple stars
approach (*, **, ***) though since that allows us to avoid making
leading whitespace significant and aligns well with the multiple hashes
approach that we use for headlines (#, ##, ###).

My 2c,
  Gary

-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Why is HTML email a security nightmare? See https://useplaintext.email/

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

Link to individual message.

---

Previous Thread: [ANN] GemIF - Simple Interactive Fiction engine for Gemini

Next Thread: Hosting several sites on the same host