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