-
-
Notifications
You must be signed in to change notification settings - Fork 787
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Emit toc for manpage #4533
Comments
Can you point me to an existing man page that has a TOC? This seems like a very personal request and not one that's likely to be used or expected by most users. Plus, if we start adding a TOC now, it could be extremely disruptive to existing users who are not expecting the man page to have a TOC. This feels like something that should be handled by an extended converter. |
The reason why there aren't any manpages with toc's is because pagers haven't yet caught up to OSC-8 based hyperlinks (OSC-8 is pretty new). Here's an ongoing PR in |
It's not really about how easy it is, but how disruptive it would be. It has the potential to break a lot of existing builds since there was never any expectation before that a TOC would be generated in manpage output (and, like I said, it's very atypical for man pages to have one). We could possibly consider having a dedicated attribute that controls whether the TOC is generated when producing a man page ( |
It's true that man pages generally don't construct their own TOCs by hand. There are exceptions like top(1). It's a good thing they don't, as the formatter could do so itself depending on the output device. And that is in fact how the PDF bookmarking and HTML navigation bar works (albeit with the latter presented in an ancient, dot-com-era style rather than HTML5). So I don't know that there is much for |
I just don't see the justification for using a TOC in the manpage output (toc is definitely support for HTML and PDF output). I've never seen a man page with a toc. |
As I noted in my comment from March 24, there is top(1), from procps-ng. https://gitlab.com/procps-ng/procps/-/blob/master/man/top.1?ref_type=heads#L99 However, that page is not an idiomatic man(7) document in my opinion as a groff developer (and contributor to its own man pages as well as those of ncurses, procps, bash, and others). That document would be better migrated to an ms document like the good old Volume 2 of the Seventh Edition Unix Programmer's Manual (1979) and replaced with something leaner in man. But, not my project, not my decision. |
I am sorry to see this consciously so late, dear 0-issue!
in your manual page, it will be generated (for the given document types). Now it must be said, whereas less(1) started supporting the TTY-wise machinery in January this year, the groff maintainer which has spoken up here already did not only implement the OSC8 feature so that less(1) and i have to use non-OSC8-"standard" means to create anchor-only constructs, but he also rejected upstreaming mdocmx and in the meantime has meddled with the mdocmx macros in a way that i can no longer follow upstream due to time constraints. My initial dream was that we go away from HTML etc documentation to simply UNIX manuals on the terminal, but with internal and external links, and an optional toc (which could have ended as "man -toc" or whatever, you know). So being able to drive a TOC for a TTY manual display in a fixed way is possibly a bit odd, if it is optional i personally am all for it!! (Sorry again, 0-issue. Thanks for speaking up with Mr. Nudelman!) |
And I am sorry to see you repeating irrelevancies and falsehoods here just as you have in so many other forums.
I don't agree with this approach in the slightest. The point of the man and mdoc formats is to describe a document (one which in turn describes some aspect of a Unix system). There is no reason for such documents to carry internal information directing the presence or cosmetic arrangement of a navigation feature like a table of contents. What if a tree is not the arrangement preferred by the reader? What if a simple list is easier for, say, a screen reader used by the visually impaired? The man page author need neither know nor care about such things; all they need to do is structure their document. A similar argument goes for this list of output formats, which is (a) groff-specific and (b) fails to mention several groff output devices, including but not limited to
The best avenue for manipulating of table of contents (TOC) generation or similar features is likely the specification of registers or strings on the roff command line, as is already the case with many cosmetic details.
There is no standard for OSC 8, just a convention, and there is no convention for anchor placement that anyone but you has proposed. If you disagree, please cite the discussions and tell me why the groff mailing list was never notified of them. I foresee adding automatic placement of anchors linked to (1) section headings, (2) subsection headings, and (3) the "tags" of tagged paragraphs (
That's true. mandoc(1) maintainer Ingo Schwarze also objected to your design and implementation.
This is not only false but nonsense. There are no mdocmx macros in groff, so I can neither meddle with them nor leave them alone. They do not exist. If you are attempting to claim some sort of ownership over man or mdoc package internal interfaces to suit your own aims, that claim is unwarranted and untenable.
Good luck with your Steve Jobs-scale ambition to steer the public. My own objective is more modest: to get as much out of the man page browsing experience on the terminal as we can, so that people seldom feel a need to fire up a web browser (or PDF viewer) to peruse a man or mdoc document. Such output formats will still be necessary for some purposes, and I'd like groff to produce high-quality renderings in them. (I think we're much closer to that goal with PDF than with HTML.)
It's fine to have a TOC. Plenty of Web conversions of man pages infer a tree structure from a document and construct a TOC therefrom. My impression is that these converters are often ad hoc and frequently fail to produce such content in an idiomatic HTML5- or WAI-ARIA-conforming manner. I certainly don't mind making that job easier. What I object to is requiring man or mdoc authors to specify anything in particular about such a tree or TOC. They already specify a document title, section headings, and sometimes subsection headings and paragraph tags. These are already hierarchically arranged in a tree structure. That is enough. No more need be said. In particular, anything like...
...is wholly superfluous.
It's pretty sloppy of you to continue to refer to terminal emulators as "TTY"s when Teletype machines, being paper-based devices, were inherently incapable of hyperlinking. OSC 8 is wholly alien to that technology. Its very syntactical structure is foreign to such devices. This sort of confusion between paper teletypewriters and cursor-addressable video terminals has been responsible for much misunderstanding and poor decision-making in the use and development of Unix software, particularly pagers like less(1). Please cease your guerilla campaign of confusing issues and mystifying developers. Regards, |
While I don't disagree with the rebuttal, I'm going to stop this conversation here because it has drifted into a broader debate about how man pages should be authored. You're welcome to continue this debate somewhere else. As far as this issue is concerned, if you need a TOC included in the manpage output (whether it's done manually or using a custom macro), you can do so by extending the manpage converter. You can learn how to extend the converter on the following page in the docs: https://docs.asciidoctor.org/asciidoctor/latest/convert/custom/#extend-and-replace-a-registered-converter |
It would be nice to have a
:toc:
emitted for manpages. Manpage viewers are starting to consider exploiting OSC-8 sequences to make man pages browsable, and table of contents will become even more relevant (to jump links within same page). If you would want, I can file another issue for supporting OSC-8 sequences (groff already supports them) for all hyperlinks.The text was updated successfully, but these errors were encountered: