Files not in SUMMARY.md are not parsed

[ghost]

Hi,

I'm using binary v0.1.7. Currently files which are not in SUMMARY.md are not parsed. I manually link them inside other files (to make the left menu short). May I ask if you could add support to parse those files?

Thank you,

---

Edited

I think this could be easily solved. If some of you could give me some hint, I would be happy to code.

[Michael-F-Bryan]

This is actually the main purpose of the SUMMARY.md file, you use this to tell mdbook which files you'd like to be present in the rendered document. It's analogous to the table of contents in a book.

Using that analogy it sounds like you're asking to be able to add chapters to a book without referencing them anywhere in the table of contents.

[ghost]

@Michael-F-Bryan

Thank you I understand.

In my use case, there would be too much chapters (in deep levels), so I would like to not have them in the TOC. Instead, I manually link them in other chapters (which are listed in SUMMARY.md file.

If implemented, I think the navigating via left/right arrow keys/buttons would need to be updated too. Some solutions might be:

• Keep them target the official chapters in TOC.
• Let a page define targets so parser can parse. (I prefer this solution, I think the user is more likely to expect it to work this way.)

To compare, the TOC in a PDF file does not always list all chapters the file has. When the user is reading some unlisted chapters, which are inside an official chapter, the indicator still points at that official chapter.

Do you think this is a good approach?

[azerupi]

In my use case, there would be too much chapters (in deep levels), so I would like to not have them in the TOC. Instead, I manually link them in other chapters (which are listed in SUMMARY.md file.

I have thought about this in the past. There could be multiple solutions for this specific problem. Currently I can think of two possible solutions that could improve this use case:

1. Define a new chapter type for the SUMMARY.md that is part of the books structure but not shown in the TOC. It would be the most configurable option but it is a manual process and having different levels of chapters being hidden or shown depending on the authors will could be confusing for the reader.
2. Define a max nesting level that is displayed in the TOC. All sub chapters would be hidden. You could also collapse/expand the TOC in function of the current chapter being read in order to keep the size of the TOC small but still display all the sub-chapters around the current chapter.

[ghost]

@azerupi

Thanks, I like your #2 solution. However as I was thinking, I thought of an idea similar to old PHP forums. If there are many sub chapters, the TOC tree could look like this:

1.
2.
    2.1
    2.2
    2.3
    ...
    2.100
3.

If the user is reading 2.50.9:

1.
2.
    2.1
    ...
    2.49
    2.50
        2.50.1
        ...
        2.50.8
        2.50.9
        2.50.10
        ...
        2.50.100
    2.51
    ...
    2.100
3.

Those examples limits sub chapters being shown to 3. I think this number should be configurable in book.toml.

This solution doesn't need to update current navigation code (left/right arrows).

However I have almost no experiences in JavaScript :-( But I can code Rust.

[rawkode]

Using that analogy it sounds like you're asking to be able to add chapters to a book without referencing them anywhere in the table of contents.

I want to be able to add chapters, but I don't want to list every page in the summary; which is what is required now.

My use-case is to have FAQs, with each Q/A being it's own markdown file.

I don't want to add every FAQ to the summary, just a title page

[sdruskat]

Another use case for files that should be parsed but are not in SUMMARY.md is the following:

I'm creating Javadoc API documentation in Markdown during build time of my Java project. The resulting files (names, number) and directory structure may change arbitrarily, but the "start page" stays the same, say, javadoc.md, which links to all generated pages.

If I only refer to the "start page" in SUMMARY.md, all the linked to pages aren't rendered, and all the links are dead.

# Summary

- [Chapter 1](./chapter_1.md)

[Javadoc](./javadoc/javadoc.md)

It'd be great to have a flag or option in book.toml that could switch on such behaviour.

[DannyBen]

I know this is an old issue, but I came to search issues for a similar problem.

I would love it if there was a simple way to render some files, while not showing them in the summary. In my particular use case, I would like to have pages that are linked from other pages, but should not appear in the table of contents.

A simple solution in my mind (from the user standpoint), is to have an intuitive marker in the SUMMARY.md file to denote it. I was thinking about the markdown hr notation, ---

So it would be like:

# Summary

- [Title](url)
  - [Title](url)
  - [Title](url)
- [Title](url)

---

- [Hdden File Title](url)
  - [Hdden File Title](url)
  - [Hdden File Title](url)
- [Hdden File Title](url)

which means, that the user has the same control over the path that these files, and:

1. The function that generates the pages ignores the hr
2. The function that generates the sidebar stops at the first hr

I hope this (or a similar) implementation is considered.

[jikkujose]

Ability to create pages based on links in the page would be super nice. Things like "expanded footnote" can be handled without adding an entry in ToC.

I will argue this is important & relevant because unlike a physical book people don't navigate/explore a book via ToC. ToC is just a high level map rather than an exact mapping to every section of a book. Unlike a physical book, such a digital book has search making it the preferable way to find something irrespective of whether its available in ToC or not.

Additionally if such a feature will can be used for vimwiki& similar projects.

Instead of getting the list of files to compile from Summary all that needs to be done is to just compile all markdown files in src folder.

[TeomanEgeSelcuk]

In my use case, there would be too much chapters (in deep levels), so I would like to not have them in the TOC. Instead, I manually link them in other chapters (which are listed in SUMMARY.md file.

I have thought about this in the past. There could be multiple solutions for this specific problem. Currently I can think of two possible solutions that could improve this use case:

1. Define a new chapter type for the SUMMARY.md that is part of the books structure but not shown in the TOC. It would be the most configurable option but it is a manual process and having different levels of chapters being hidden or shown depending on the authors will could be confusing for the reader.

2. Define a max nesting level that is displayed in the TOC. All sub chapters would be hidden. You could also collapse/expand the TOC in function of the current chapter being read in order to keep the size of the TOC small but still display all the sub-chapters around the current chapter.

I like the first proposed option, I would like to do this however i do not know how to replicate this. Can someone show me the structure of chapter types in SUMMARy.md and the dependency of having to have all pages in the TOC.

[tkurki]

My use case for this is to include .md content generated from API descriptions and include in SUMMARY.md just the "start page" of that collection of interlinked .md files. When navigating to these subpages the navigation should show the parent start page as selected per solution "chapter type not shown but part of the book structure".

[veeshi]

We have a similar use case where we are automatically generating hundreds of pages of markdown docs and it is quite painful and error prone to copy in those sections to the SUMMARY.md and any changes we've made.

[n8behavior]

I'm also trying to do something similar with adrs, a Rust-base CLI tool which creates ADR files and generates a TOC for each decision. Same would be true for adr-tools and the many other CLI ports.

This point being that there are many tools that generate and manage collections of markdown files, wikis come to mind, that are already linked in a specific way. Being able to the starting page(s) of a collection without having to manually link every page in the collection via SUMMARY.md seems reasonable and doable.

I see this has been asked for in many other issues and all have been closed accept #703 and #830. I'd be interested to tackle this issue, but don't want to tackle something that's going to be rejected because the maintainers don't like the idea. It would be helpful if the maintainers could indicate a preference or that they feel the current all-pages-must-be-in-the-summary approach is what they want.