scroll(1) – pager
I have a particularly bad one in my source tree. It was less useful once I'd figured out I could scroll my xterms but nowadays I just use…
rtfm(1) - manual pages
Could # headers be specifically for title/section metadata?
For example, roff:
.TH PAGE 1
and my proposed equivalent usage in doc:
# PAGE(1)
Or PAGE 1 or…
In C - I can't speak as to how Rust does it - enums are basically #defines as they replace a given symbol with another symbol, though unlike #defines the symbol remains in the code rather than…
yes(1) analogue
On second thought, I'm fully on board with dropping printf(1p) and using format(1). I wonder if the name could be better though - I still think "format" is vague.
I don't think out(1) is…
It looks like dc(1) historically also had this issue. I'd really like to not have it though and I might try to fix this myself.
"Rpn evaluates a given reverse polish notation expression according to the conventions defined in rpn(7), printing the last item on its stack on completion."
"Otherwise, it reads a newline-delimited series of numbers and integers from standard input."
I would classify this as a bug, not a caveat, and refrain from mentioning implementation details in the man page.
I don't think this caveat is needed here, maybe there should be a float(7) that explains IEEE-754 and its caveats.
Integers and operations can be mixed. I would classify an integer as an operation, too - the push operation.
If this were C I would put the sentry value first so validity is just a measure of whether or not the enum is 0. I don't know if Rust works that way but it's a thought. It may also make more sense conceptually if Empty and Val are the zeroth and first enumerations respectively.