Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Man gen #6

Merged
merged 12 commits into from
Jul 24, 2018
Merged

Man gen #6

merged 12 commits into from
Jul 24, 2018

Conversation

yoshuawuyts
Copy link
Collaborator

Adds the man page generation code. Includes an example. Works towards: https://github.com/rust-lang-nursery/cli-wg/issues/42.

Review-wise, this PR is pretty early. I would like to ask to discuss any API design issues in #2, and focus the review on implementation issues only.

Once we land this the next step would be to wire it up to structopt to hit the milestone's goal. Thanks!

Example Output

2018-07-19-141825_1920x1080

@yoshuawuyts yoshuawuyts added the enhancement New feature or request label Jul 19, 2018
@killercup
Copy link
Contributor

Once we land this the next step would be to wire it up to structopt to hit the milestone's goal.

I've only briefly looked at this -- this might require you to port structopt to clap 3, right? Maybe we should change the milestone to target clap_derive instead?

@yoshuawuyts
Copy link
Collaborator Author

@killercup I'm okay with that, but it's worth noting that clap_derive is still in flux. Tested it a few weeks ago and couldn't get it to compile. Insgead we should perhaps just target clap3 for the initial demo?

}
```
Preview by running:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hate that you don't put empty lines around code blocks. Just so you know. :P

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for sharing; your comment has been noted 😛

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a side note: I'll happily switch to whichever style is conventional the moment rustfmt is able to do so automatically. Can't be bothered to otherwise :P

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

brb, doing cargo new mdfmt


use clap::{App, Arg, ArgSettings};
pub use man::*;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd only expose some very carefully selected items.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if we can get #9 to land, this will also be solved. For now it mostly enforces the same behavior we'd have as putting everything in lib/ (e.g. less typing until we clean things up, haha).

src/man/mod.rs Outdated
/// mycmd - brief description of the application
/// ```
#[inline]
pub fn description(page: Roff, name: &str, desc: &Option<String>) -> Roff {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this marked as inline? The compiler should be clever enough to inline this if wise.

And why is it public? It's only used in render, right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same for all the fns below

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking of exposing them all as public, but I reckon you're right and we should just keep them private. Will change!

description: Option<String>,
argument: String,
default: Option<String>,
) -> Self {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's quite a lot of params for one function.

Looking at this it might make sense to make the underlying Option type public (but not its fields) and expose a builder patter for it, too. (You can probably use a derive).

Same for consistency's sake for the other similar methods.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, thinking something along the lines of #2 (comment) would be better.

I kind of want to merge the API so we can start working on demos; and then quickly follow it up with a separate API to get the naming and things closer to what's outlined in the issue above. Definitely agree this should be better!

@@ -0,0 +1,6 @@
/// An author entry.
#[derive(Debug)]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can probably also derive Clone. Not necessary right now but you're not using Debug, too

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point!

@yoshuawuyts
Copy link
Collaborator Author

I think this should be good enough for now. - Going to merge so we can continue hacking on this ✨

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants