[Feature Request] Automatic Numbering of headings

đź’» Development
1

If a heading starts with a digit, automatic numbering is activated. Existing heading numbers in the document are replaced. The numbering is updated continuously while editing.

  • If the digit-sequence ends with ". ", all sibling headings receive a number (same hierarchy level and same parent heading). Numbering starts with the number given in the first sibling.
  • If the digit-sequence ends with " " (no dot), all headings under the same parent heading are numbered automaticly. Numbering starts with the number given in the title. All headings below will show this number and all other numbers in number heirarchy, separated with a dot. If the numbering was not triggered in a hierarchy level, a number is added anyway. To choose the number, the starting number of the parent is reduced by 1.

Nice to have: table of content (TOC)

  • If the title starts with an asterisk in front of the digit-sequence, an expandable section is inserted immediately above the first numbered title. The section contains an ordered list of all titles. The index is updated continuously while editing.
  • The collapsible section receives the title «Table of content», in the users preferred language, according to his account pofile. Users may edit the section title and move the section to any position within the document (using copy-paste or cut-paste) without breaking the functionality. If multiple indexes are present in a document, all indexes are updated.
  • In the print css, the toc is always shown (never collapsed). The TOC title will be placed on a separate page. Page-wrapping will only occur before a heading with children, but never within siblings unless none of the siblings has children.
  • In a future release of the text-app, headings may always receive an anchor id. Starting with that release, the headings in the TOC will be hyperlinks.

Nice to have: Alternate numbering schemes
For the first type (non scientific Numbering), alternate schemes may be used instead of digits (a., A., i., I., non-latin, …)

Nice to have:

  • On Screen, all numbered headings receive a triangle icon to the left. Clicking the triangle, the whole text may be collapsed.
  • On large screens, when not using the full-with-editor, if there is enough width outside the text column (~20em, 10em on both sides), the space on the left of the column is used to display the TOC to navigate withing the document (CSS display: fixed). Users may collapse and expand Headings in the TOC.
    If a heading in the TOC is clicked, the document is scrolled to the position so this very title appears in the middle of the window height. The text of this title in the editor is selected.

Examples:

  • the first H2 starts with "1. ":
    âžť H1 is not numbered (unless the first H1 sibling starts with a number)
    âžť all H2 below the same H1 parent will be numbered
    âžť H3 will not be numbered (unless the first H3 sibling below the H2 starts with a number)
  • the first H2 starts with "0 ":
    âžť No H1 in the whole document is numbered
    âžť All H2 below the same H1 parent are numbered sequentially, starting with 0.
    ➝ If a H4 heading below this H2 starts with "3 ", this number is replaced with “0.-1.3”. All sibling H3 headings are numbered accordingly.
    âžť if a H5 heading below this H4 starts with "1. ", all H5 siblings are numbered as type 1 (non scientific)
  • The first H3 in a document starts with "*1 ":
    âžť the TOC is added above this H3. Users may edit the title and cut-paste the TOC

Considerations:

  • The numbering must be triggered manually on every level. While this cost minor effort, it seems tedious - at least in scientific numbering, users might want to omit this trigger. But: now and then, additional hierarchies are needed that won’t cite the numbering above.
  • The functionality could be realized by using css class definitions implementing the numbering. However, inserting the numbers in the markdown source code seems more robust.

((edited 2026-07-17 08:20 UTC: description with less ambiguity))

2

Hello @wintifrosch,

you started a topic in development category. This category is intended for active developers of the core or apps in the Nextcloud ecosystem.
From the description in your topic, it is not clear if you are seeking help and advice about a concrete problem you have or you want to actually develop the corresponding solution. I assume from your way of writing that you expect these features to be implemented for you (aka this is a feature request)

Please specify explicitly the required information to help you best. These are:

  1. What you want to achieve
  2. What you have done so far
  3. What is failing
  4. What you expect from the forum community

Without additional information the community members cannot help you in an efficient manner. Please keep in mind that the help here in the forum are mostly based on work of volunteers and thus it is just fair to reduce the burden on them.

If you accidentally posted in the category, just give a hint and a moderator can move the corresponding category.
Especially, if you want to report an issue (like a found bug) for the corresponding developers to address, this is unfortunately not the right location: most devs will not likely stumble upon the issues in the forum. Such issues are better tracked on GitHub in the appropriate issue tracker. Probably, this is the issue tracker of the server but could be another one as well.

You mentioned multiple issues/features. For the sake of simpler work, please address each feature separately In its own issue. You can cross-links them if needed to explain.

Regards,
christianlupus

3

Hi @christianlupus,

thank you for your clarification. You are right that my original post combines several different feature requests and does not make clear what I expect from the forum. I was also not yet aware of Text’s existing outline view when I wrote it.

I will separate the additional ideas such as a table of contents, collapsible sections, and outline navigation from the main subject.

The main issue I am investigating is automatic heading numbering in a Markdown editor. The difficult part is not merely displaying numbers: an editor needs to distinguish numbers that it is allowed to update automatically from numbers that the author entered as literal heading text and that must remain untouched. For interoperability, that distinction would ideally be represented in the Markdown file itself rather than only in editor-specific state.

I have therefore opened a discussion in the CommonMark forum to ask for feedback on interoperable markers and their possible semantics:

Interoperable markers for automatic heading numbers

At this stage, I am not asking the Nextcloud forum community to implement the feature. I first want to clarify whether a usable and reasonably interoperable Markdown representation can be found.
Once that question is clearer, I intend to formulate a much narrower feature request for the Nextcloud Text issue tracker, referring to the CommonMark discussion. That request would concern only the editor behaviour and its implementation in Nextcloud Text.

So, in terms of the points you listed:

  1. What I want to achieve: Allow an editor to maintain heading numbers automatically without modifying manually authored numbers.
  2. What I have done so far: I have separated the underlying Markdown-interoperability question and opened the CommonMark discussion linked above.
  3. What is currently missing: There appears to be no interoperable way for an editor to identify which heading numbers are automatically managed.
  4. What I expect from this forum: For now, only guidance on whether this topic should remain here, be moved, or be closed in favour of a later, focused issue in nextcloud/text.

Please feel free to move this topic to a more appropriate category. Alternatively, it can be closed, and I will add a link here when the focused Nextcloud Text issue exists.

Thanks again for pointing out the problems with the original request.