Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR introduces HTML rendering of Markdown files, as announced in #2565. The main usecase is rendering
README.md
files accompanying a package.If a file has the
.md
extension and can be parsed by the MMark parser, we display both the HTML output generated by MMark, and the Markdown sources, which are hidden by default using a<details>
tag. If a problem occurs in the parsing phase, we treat the file as plain text and display a warning.One issue that I am aware of is handling of local (non-external) links. For example in the Prelude's
README.md
we have a link pointing to./Natural/fold
. In the generated documentation this will stil point to./Natural/fold
, but there is no such file in the docs: we are missing the.html
extension. (And for links to folders we should add a trailing/index.html
.) A "full" solution of this could be rather tricky, as it should involve handling of symlinks etc., and would probably need IO and some restructuring of the code. I think a simple solution that works in most real-life scenarios can be implemented using a MMark extension, a helper function similar toshake
'sNormaliseEx
and the list of rendered files. However, this would still require some work, and I believe the present changes already improve thedhall-docs
tool a little bit, so I'd rather take care of this in a separate PR. (Moreover, rendering of comments in.dhall
files has the same issue, so it could be fixed in both places at once.)