-
Notifications
You must be signed in to change notification settings - Fork 30k
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
doc: refactor manpage to use mdoc(7) macros #18559
Conversation
Fixes: #18434 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
I'm not particularly knowledgeable about man pages, but as long as I'm not really sure who to cc for this, I'm not sure we have anyone who is particularly knowledgeable about the Node manpage. Maybe cc/ @silverwind @bnoordhuis @sam-github @strugee (from the commit history). What would be really helpful is a way to evaluate PRs to the manpage. A rendered before/after might be adequate, how did you generate yours? |
I'm not an mdoc expert (wrote a lot of roff in my time but not mdoc specifically) but the changes look good to me. @Alhadis Can you wrap lines at 80 columns and spice up the commit log?
I'm not 100% sure but I think that's the case. It's probably an improvement over the current man page because I doubt it renders nicely when your roff isn't groff. |
I can, but having one sentence per line enables Troff (or mandoc) to generate nicer-looking paragraphs with better justification. Compare:
Not a huge issue (unless you're a typography nerd like me), but you'll notice λ node (docfix): mandoc -T lint doc/node.1
mandoc: doc/node.1:28:17: WARNING: new sentence, new line @bnoordhuis How should I proceed?
Using this, which started from this. Don't want this PR to become an advertisement for my own handiwork, but suffice to say if you're an Atom user, you'll damn well enjoy having a live previewer for editing Roff documents. It's not strictly reliant on Atom to work, either: its non-graphical output can be used from within Node alone: groff -mandoc -tZTutf8 /path/to/man/page.1 | html-tty > wanky-preview.html With Note: The previewer isn't finished, although it's 95% there. I'm itching to finish it. |
doc/node.1
Outdated
.TP | ||
.BR \-\-zero\-fill\-buffers | ||
. | ||
.It Fl -redirect-warnings Ar file |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add the equal signs back on arguments like −−redirect−warnings=file
? From a quick glance, it looks like the parser is strict about them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean? Every time I pass --redirect-warnings=file
(with or without an equals-sign), I get the same error telling me it was given a bad option.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the option may be actually broken, let me check for another example.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Better example: node --inspect=1234
works while node --inspect 1234
does not. (Yeah we should really fix our argparser)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#18580 for the --redirect-warnings
issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#18580 resolved. The HTML you generated includes
U+2212 minus signs which of course throws our parser off as it expects ASCII. The issue appears to not be present in the manpage.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"The issue appears to not be present in the manpage"
When you say it's not present, which manpage and manpage version are you specifically referring to? If you're testing them locally, compare the output of these two lines, please:
groff -mandoc -tTascii ./node.1 | less # Boring old ASCII
groff -mandoc -tTutf8 ./node.1 | less # UTF-8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Either way, it seems the =
is necessary, so @Alhadis would you mind adding it back in?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't it be better to explicitly mention the option requires an equals sign? It isn't immediately clear to the reader that the discrepancy is deliberate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't it be better to explicitly mention the option requires an equals sign?
Not sure I follow. Do you mean adding a "This option requires a equal sign" to each option that does? I'd rather just print it as part of the option title, much more concise.
doc/node.1
Outdated
.It Fl \-experimental-vm-modules | ||
Enable experimental ES module support in VM module. | ||
. | ||
.It \- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this -
be highlighted as a flag?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not a real flag, as such. Both -
and --
probably shouldn't even be documented here. I'd move them back up to the DESCRIPTION
block, next to the line about no arguments enabling the REPL.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds fine to me, they aren't really options, but I see some value having them documented.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OTOH, I just noticed that for example git
seems to also list --
under options, see git-commit(1)
. So maybe it's not that uncommon to list --
and -
as options.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it is going to stay here (which seems fine to me, especially given the git-commit
example) then I guess bolding the -
and --
makes sense.
.\" See http://liw.fi/manpages/ for an overview, or http://www.troff.org/54.pdf | ||
.\" for detailed language reference. | ||
|
||
.\" Macro to display an underlined URL in bold |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd suggest retaining a informational header about the file format because many people are not familar with the arcane art of writing manpages. A few links to the format and maybe a example on how to lint and preview should be enough
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I somehow missed this comment. And yep, I'll definitely add a header with some links to informative resources... I held off doing this for the same reason as the commit message: I wasn't sure how it would be received (and I'm absurdly OCD about well-written commit messages, sometimes to a point of being manic). 😅
Overall, I like the new concise rendering 👍 @Alhadis By the way, which tool would you recommend for linting? I see you've been using |
Which Linux are you referring to? I had no problems installing it on Debian, and the project's site has a pretty comprehensive listing of ports and supported platforms. For typesetter-roff ( troff -tTutf8 -wall /path/to/page.1 >/dev/null |
Arch Linux does not have it in the base repos, just in AUR, but that shouldn't be an issue for a possible future integration of a manpage linter if our lint job node-test-linter runs on a Debian derivate, but I'm not certain right now. |
Linter job currently runs on FreeBSD, but I don't think moving to debian will be an issue. |
Anybody want me to chuck this in as a bonus? 😀 It's a few years out-of-date and needs updating with V8's new command-switch set, but I've been meaning to hack a Perl script together to sync the The page was hard-written but works beautifully. |
I wouldn't be against adding v8 options to the man page if you can get the updating integrated into our v8 update workflow (I think this is done using https://github.com/targos/update-v8). Would probably have to be written in JS, thought :) cc: @targos |
Updating a manual-page by comparing two lists of options gets a bit slippery because many of the manpage option-descriptions have been polished up in grammar or wording, possibly with marked-up links to other sections across pages, or what-have-you. =) (I'm hoping that makes sense). FYI, it wouldn't take me very long to smash together a Node program that generates the API manpages from JSON source. 😉 |
Given that it's a BSD, it might just have the
I see that most v8 options are pretty inconsistently labeled. One suggestion might be to maintain a list of polished up descriptions and fallback to the default description in case no mapping is found. |
Sounds useful, but it might delay this PR, maybe just raise a separate one.
Please do! |
Will do. ;) Just waiting on @bnoordhuis to clarify what he wants me to do regarding that line-wrapping matter. Then I'll amend my commit and force-push something merge-worthy. 👍 |
It's fine but can you add a comment to the document explaining why it has long lines? Otherwise someone will clean it up sooner or later. |
Wilco. =) I'll include a note about why blank lines are bad, too. |
Alright, done. Does that look adequate? I started with the .ig
This manpage is written in mdoc(7).
* Language reference:
https://man.openbsd.org/mdoc.7
* Atom editor support:
https://atom.io/packages/language-roff
* Linting changes:
mandoc -Wall -Tlint /path/to/this.file # BSD
groff -w all -z /path/to/this.file # GNU/Linux, macOS
Before making changes, please note the following:
* In Roff, each new sentence should begin on a new line. This gives
the Roff formatter better control over text-spacing, line-wrapping,
and paragraph justification.
* Do not leave blank lines in the markup. If whitespace is desired
for readability, put a dot in the first column to indicate a null/empty
command. Comments and horizontal whitespace may optionally follow: each
of these lines are an example of a null command immediately followed by
a comment.
.. Of course, then I had to explain (tersely) what the |
Out of interest did you edit your commit message to make every line exactly 72 columns? If so then I'm kind of amazed by the commitment 😁 .
Also do you have an updated rendered link to compare against? |
That's, uh, literally every commit message I've ever written. 😅 I'm not even making this up. Think that's absurd? Scroll down.
Output is still the same. 😉 All I did was add comments: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM once @silverwind 's comments are addressed
doc/node.1
Outdated
.It Fl \-experimental-vm-modules | ||
Enable experimental ES module support in VM module. | ||
. | ||
.It \- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it is going to stay here (which seems fine to me, especially given the git-commit
example) then I guess bolding the -
and --
makes sense.
doc/node.1
Outdated
.TP | ||
.BR \-\-zero\-fill\-buffers | ||
. | ||
.It Fl -redirect-warnings Ar file |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Either way, it seems the =
is necessary, so @Alhadis would you mind adding it back in?
Yeah, I'd approve as well once those two points are adressed (boldening of |
Like man(7), mdoc(7) is a macro package for marking up computer manuals. The main difference is that mdoc is semantic rather than presentational, providing authors with a full DSL to abstract page markup from low-level Roff commands. By contrast, `man` is minimalist and leaves formatting to the author, who is expected to have a working amount of Roff knowledge. Therefore the use of `mdoc` for marking up Node's manpage is a decidedly better choice than bare `man`. Less room is left for error and mandoc(1) offers very robust error-checking and linting.
Very well. Done. Here's the updated rendered view. To explain the It's necessary to stop |
Like man(7), mdoc(7) is a macro package for marking up computer manuals. The main difference is that mdoc is semantic rather than presentational, providing authors with a full DSL to abstract page markup from low-level Roff commands. By contrast, `man` is minimalist and leaves formatting to the author, who is expected to have a working amount of Roff knowledge. Therefore the use of `mdoc` for marking up Node's manpage is a decidedly better choice than bare `man`. Less room is left for error and mandoc(1) offers very robust error-checking and linting. PR-URL: nodejs#18559 Reviewed-By: Roman Reiss <me@silverwind.io> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Like man(7), mdoc(7) is a macro package for marking up computer manuals. The main difference is that mdoc is semantic rather than presentational, providing authors with a full DSL to abstract page markup from low-level Roff commands. By contrast, `man` is minimalist and leaves formatting to the author, who is expected to have a working amount of Roff knowledge. Therefore the use of `mdoc` for marking up Node's manpage is a decidedly better choice than bare `man`. Less room is left for error and mandoc(1) offers very robust error-checking and linting. PR-URL: #18559 Reviewed-By: Roman Reiss <me@silverwind.io> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Like man(7), mdoc(7) is a macro package for marking up computer manuals. The main difference is that mdoc is semantic rather than presentational, providing authors with a full DSL to abstract page markup from low-level Roff commands. By contrast, `man` is minimalist and leaves formatting to the author, who is expected to have a working amount of Roff knowledge. Therefore the use of `mdoc` for marking up Node's manpage is a decidedly better choice than bare `man`. Less room is left for error and mandoc(1) offers very robust error-checking and linting. PR-URL: #18559 Reviewed-By: Roman Reiss <me@silverwind.io> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Like man(7), mdoc(7) is a macro package for marking up computer manuals. The main difference is that mdoc is semantic rather than presentational, providing authors with a full DSL to abstract page markup from low-level Roff commands. By contrast, `man` is minimalist and leaves formatting to the author, who is expected to have a working amount of Roff knowledge. Therefore the use of `mdoc` for marking up Node's manpage is a decidedly better choice than bare `man`. Less room is left for error and mandoc(1) offers very robust error-checking and linting. PR-URL: #18559 Reviewed-By: Roman Reiss <me@silverwind.io> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Like man(7), mdoc(7) is a macro package for marking up computer manuals. The main difference is that mdoc is semantic rather than presentational, providing authors with a full DSL to abstract page markup from low-level Roff commands. By contrast, `man` is minimalist and leaves formatting to the author, who is expected to have a working amount of Roff knowledge. Therefore the use of `mdoc` for marking up Node's manpage is a decidedly better choice than bare `man`. Less room is left for error and mandoc(1) offers very robust error-checking and linting. PR-URL: nodejs#18559 Reviewed-By: Roman Reiss <me@silverwind.io> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
NOTE:
A correctly-written commit message will be amended and force-pushed once a maintainer gives their approval. Due to the rather ambitious nature of this PR, and the fact it targets an ancillary part of Node's codebase, I expect this to be rejected. I thought to try nonetheless.
Checklist
Description
This is a refactoring of Node's manpage to use
mdoc
macros instead of the legacyman
macros. Both are widely supported, and both are used to format manual-pages for terminal display. The key difference is thatmdoc
is semantic rather than presentational. It offers less control over arbitrary formatting, but generates very consistent output. Its syntax is a little unwieldy but leaves less room for error. See mdoc(7) for reference.Realistic preview of changes
man
macros)mdoc
macros)Some minor editorial changes were made so the page conforms to the structure and conventions of manpages. In addition, the
--experimental-modules
and--experimental-vm-modules
switches were added to theOPTIONS
section, which are currently listed in the output ofnode --help
.