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

feat: generate json help strings for use in docs/website #2158

Closed
wants to merge 1 commit into from

Conversation

jcollie
Copy link
Collaborator

@jcollie jcollie commented Aug 28, 2024

note that this code should eventually be used to enhance the helpgen and the man pages since it goes a bit deeper and pulls out doc strings for enums.

@@ -3449,6 +3450,8 @@ pub const Keybinds = struct {

/// Like formatEntry but has an option to include docs.
pub fn formatEntryDocs(self: Keybinds, formatter: anytype, docs: bool) !void {
if (build_config.building_docs) return;
Copy link
Contributor

Choose a reason for hiding this comment

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

What's going on here? Just trying to understand it :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It's a chicken-and-egg problem. While building the json & help strings docs you don't have access to the help strings so you get an error trying to import help_strings. Turning formatEntryDocs and one other spot into no-ps when building the json & help strings fixes that.

@mitchellh
Copy link
Contributor

Sorry for the late review here... trying to dig myself out of the PR hole now. 😄

I think what I'd rather see for longer term maint is a generalization so that things like jsongen.zig aren't so long. What I mean specifically is that I'd like to see a file probably in src/config that does @embedFile("config.zig") and generates all the rich structures (at runtime since we need an alloc I think) that we can use for both mdgen and jsongen. This could then be unit tested.

I think we could further continue to use this in different places so that we aren't reimplementing all the parsing and extracting each time.

I don't like closing PRs, but doing this myself would be a lot of work and I think it'd be better to open a new one with this work. In the new PR I'd love to just see the parsing part (and probably converting mdgen). Smaller PRs get merged faster. 😄

@mitchellh mitchellh closed this Sep 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants