Respect display order #6142
Respect display order #6142
Conversation
|
Likely won't get to this until Monday but a couple of notes
|
thomas-zahner
force-pushed
the
respect-display-order
branch
2 times, most recently
from
456552a to
3838990
Compare
| } | ||
|
|
||
| #[test] | ||
| fn configured_subcmd_order() { |
There was a problem hiding this comment.
Please add all new tests in the first commit
There was a problem hiding this comment.
Looks like all of the commits had been squashed. What you did with the test commit before the main commit was right, just more tests had been added in the "fixup".
There was a problem hiding this comment.
Ah I see, I misunderstood then. I've now split the commit into everything test related and then the fix itself.
There was a problem hiding this comment.
Note that the the commits should still be atomic, including each commit passing tests. The first commit should pass, showing the current behavior. The second commit should still pass, showing the new behavior.
The intent with this split is to
- Verify the tests test the right behavior by seeing them change
- Provide a visual demonstration of what this PR accomplishes by the diff between the two commits
thomas-zahner
force-pushed
the
respect-display-order
branch
6 times, most recently
from
36cc073 to
cbeb0ba
Compare
In clap-rs#3362 we have an issue where when we configure an arg via .display_order(int), and then generate a manpage, the synposis and options will render the order the args were provided to the App rather than the order they were configured e.g Command::new(name) arg(Arg::new("few").short('b').display_order(2)) arg(Arg::new("bar").short('a').display_order(1)) will show ... SYNOPSIS <name> [-b] [-a] ... ... OPTIONS -b -a instead of ... SYNOPSIS <name> [-a] [-b] ... ... OPTIONS -a -b and so on. This fix adds sorting in the synopsis and options functions responsible for generating the corresponding synopsis and options sections of the manpage.
thomas-zahner
force-pushed
the
respect-display-order
branch
from
cbeb0ba to
1f07ad2
Compare
2 participants
This is branched off #6072 and fixes #3362. The work over at #6072 seems to have stalled. With this PR, I'd like to get the feature ready and merged.
My changes (see last commit) should resolve the comments left on the original PR. Additionally, I noticed that
option_sort_keywas fully copy/pasted on the original PR. I tried to reuse the logic and ended up creatingArgOrder. Not fully sure if this is the way to go, but I think it's quite a bit better than the current state. Especially the bit with theBTreeMapwas unnecessary andpositional_sort_keywas a overly complicated way of saying "don't do anything".Maybe you would like to implement or name
ArgOrderdifferently? Also I'm not sure where I should placeArgOrderin order to be usable in both places.