Sietse added a comment.
**NB: I was wrong about extensions not using helpcategories. I checked
something different than I thought I had. They do add categories to their
commands.**
Currently (i.e. after this patch stack, because it has been accepted) the
hierarchy (in the man page / HTML help) is like so (ignoring the fact that man
pages flatten the last few levels of the hierarchy due to less levels). As you
can see, even when a command has an existing category the command will be
displayed in that category **nested underneath the extension,** rather than
merged into the existing command category. As long as that arrangement is used,
I'd say it reduces the value of re-using existing command categories.
- COMMANDS
- Repository creation
- clone
- init
- Next category ...
- more commands ...
- EXTENSIONS
- absorb
- Commands
- Change creation
- absorb
- acl
- Commands
- more categories ...
- more commands ...
- more extensions...
- Commands
- more categories...
- more commands...
Perhaps something like this would be better. It would group by category;
extensions could add commands to existing categories; commands from extensions
would be marked as such.
- COMMANDS
- Working directory management
- status: show changed files in the working directory
- summary: summarize working directory state
- update: update working directory (or switch revisions)
- next (evolve): update to child commit, evolving history if needed
- prev (evolve): update to parent commit
Is this still the right medium for this discussion? I'm naturally interested
because I read the code recently, but I don't want to overwhelm you with
bikeshedding.
REPOSITORY
rHG Mercurial
REVISION DETAIL
https://phab.mercurial-scm.org/D6324
To: Sietse, #hg-reviewers, martinvonz
Cc: rdamazio, martinvonz, mercurial-devel
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
