Closed nverno closed 3 months ago
Thanks for the contribution @nverno 🙏
This looks like a great idea! Give me a couple of days to give it a thorough review, and I'll get back to you 🙂
When adding a test for the npm parser I realized that the buttons should be parsed differently on the main help page vs. the subcommand pages.
So, I added an argument subcommand-p
that gets passed to the button funcs and is non-nil when the help being parsed belongs to a subcommand.
LMK if that seems like an OK thing to do.
When adding a test for the npm parser I realized that the buttons should be parsed differently on the main help page vs. the subcommand pages.
So, I added an argument
subcommand-p
that gets passed to the button funcs and is non-nil when the help being parsed belongs to a subcommand.LMK if that seems like an OK thing to do.
Thanks for adding the test case for npm
@nverno 🙏
This PR looks good to me; I think my initial problem with npm
and go
was a local issue, because it works for me now 👍
What do you think about adding a way to specify how the help commands are built for a given command?
Here, I've added a
noman-help-format
variable and additional parsers fornpm
andgo
which both use the format<command> help <subcommand>
for additional help.I also simplified (I think) the parsing functions - they can return lists of (beg . end) instead of making buttons and don't take a line argument. I think they could be simplified further to optionally just be regexps, where a match would become a button.
LMK if you're interested in any of the changes and I can modify the pull request.