[REQ] Restrict list nesting depth

[mhatzl]

To nest lists, the inner list must be indented.
This leads to inner lists being more and more indented, which makes content harder to read.

Therefore, indented block elements should be restricted to a nesting depth of 6.
This is in alignment with the maximum heading level.

Implementations may set warnings for depths 5 and 6, because these are already quite unreadable.

[mhatzl]

In contrast to headings, list depth restriction should only apply to the current file.
This allows to create lists of higher depth, by inserting content from another Unimarkup file that also has lists in it.

Reason behind this workaround is to keep files readable, but allow to include other content without worrying about list depth restriction.

Explanation:

While heading levels are not affected on file inserts, the list depth increases if the content is inserted inside a list entry.
Consequently, users would need to keep track of the list depth across inserted files, which results in bad usability.

With the restriction of list depth to the current file, implementations should output an information that users should create another Unimarkup file, and insert it inside the list, if they really want to add another nested list.
Additionally, implementations should suggest to use lists instead of headings of level 5, 6, or above.

[mhatzl]

or maybe set the limit to a higher number like 250, because TOCs will be created using lists.
To allow the option to show lists inside sections, the TOC may need to have list depths greater than 6.

Maybe set a warning if depth > 4 is set manually, but allo depth up to 250 for automatically generated content.
250 should be fine even for auto-generated content, because these lists must be rendered somehow.

[nfejzic]

or maybe set the limit to a higher number like 250, because TOCs will be created using lists.

But TOCs probably won't be generated as Unimarkup content, rather they'll be rendered directly?

[mhatzl]

or maybe set the limit to a higher number like 250, because TOCs will be created using lists.

But TOCs probably won't be generated as Unimarkup content, rather they'll be rendered directly?

I would try to create TOCs using Unimarkup syntax to stay consistent, and to make it easy to adapt the TOC.

[nfejzic]

I would try to create TOCs using Unimarkup syntax to stay consistent, and to make it easy to adapt the TOC.

Can you elaborate what you mean here?

I'm thinking in terms of a macro call that generated TOC. We can generate that directly in memory and simply render to desired format.

I would not generate the TOC in Unimarkup syntax, place into the document, re-parse it, and then render to the desired format. Am I misunderstanding something?

[mhatzl]

To allow custom TOCs, it must be possible to allow TOCs to be created using macros.

Custom TOCs:

TOC, where every subheading entry is a hyperlink.
Approach seen sometimes on webpages.

Heading 1
  [Subheading 1.1](Link to heading)
  [Subheading 1.2](Link to heading)
Link to heading
  [Subheading 2.1](Link to heading)

Numbered TOC, which is common in thesis

1 Heading
  1.1 Subheading
  1.2 Subheading
2 Heading

We cannot create a generic TOC that fits all scenarios.
Therefore, custom TOCs may be created using macros.
Inside these macros, the section tree must be accessible, to iterate through all sections and their subsections.

We may provide a default TOC based on a default theme, but I do not want to force users to use it.