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

Custom Preprocessors #792

Merged
merged 10 commits into from
Oct 15, 2018
Merged

Custom Preprocessors #792

merged 10 commits into from
Oct 15, 2018

Conversation

Michael-F-Bryan
Copy link
Contributor

This lets anyone provide their own custom preprocessor by shelling out to the provided command.

CC: #762, @badboy

@Michael-F-Bryan
Copy link
Contributor Author

I think I've got the basic idea implemented, and the example program works exactly as I'd expect.

This will need a proper review and we may want to bikeshed on the nuances of how information is passed/received from the subcommand though. Plus I still need to create a new page in the user guide.

@badboy
Copy link
Member

badboy commented Oct 4, 2018

One thing I'd like to see mentioned in the docs is the handling of multiple preprocessors: Are they executed in the specified order?

And another thing: Will the input/output format be documented somewhere? This would make writing preprocessor not based on the mdbook lib possible (e.g. in other languages)

@Michael-F-Bryan
Copy link
Contributor Author

Are they executed in the specified order?

In general, I believe it'll run default preprocessors first then all other preprocessors will be run in the order they were defined in book.toml. I'm tempted to say the order will be implementation defined, seeing as it's more a side-effect of how preprocessors are discovered and not due to any explicit plan.

Will the input/output format be documented somewhere?

At the moment the format is a JSON array where the first element is PreprocessorContext and the second element is a Book, but the best reference would be the CmdPreprocessor::parse_input() helper function.

In the long term it should probably be documented, but that would mean we also need to document (and stabilize) the entire internals for Book and Config. If possible, I'd like to defer that decision until there is a need for it (e.g. someone makes an issue wanting to create a preprocessor or backend in Python).

@Michael-F-Bryan Michael-F-Bryan removed the request for review from mattico October 4, 2018 12:57
@Michael-F-Bryan Michael-F-Bryan merged commit 29f8b79 into master Oct 15, 2018
@Michael-F-Bryan Michael-F-Bryan changed the title WIP: Custom Preprocessors Custom Preprocessors Oct 15, 2018
@Michael-F-Bryan
Copy link
Contributor Author

I think this implementation for custom preprocessors is a good starting point. I've merged it so people can start using it in real-life scenarios (like @badboy's) as of the next release.

@Michael-F-Bryan Michael-F-Bryan deleted the custom-preprocessor branch October 15, 2018 16:05
@badboy
Copy link
Member

badboy commented Oct 15, 2018

Thanks!

Ruin0x11 pushed a commit to Ruin0x11/mdBook that referenced this pull request Aug 30, 2020
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.

None yet

2 participants