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

Remove square brackets when rendering HTML for footnotes #69

Merged
merged 3 commits into from Mar 12, 2018
Merged

Remove square brackets when rendering HTML for footnotes #69

merged 3 commits into from Mar 12, 2018

Conversation

pyrmont
Copy link
Contributor

@pyrmont pyrmont commented Mar 12, 2018

The current HTML renderer outputs square brackets around footnotes.

This is a test.<sup class="footnote-ref"><a href="#fn1" id="fnref1">[1]</a></sup>

This is not consistent with Kramdown's rendering (see Babelmark). I assume that this should be considered a bug given that the purpose of introducing the change was to allow the Cmark renderer to be used in place of Kramdown. It also just looks weird.

Since the bug is in the Cmark project perhaps it would be best to suggest the fix there? Sorry, this is the first time I've tried to do something like this so I'm not sure. I came across the issue when using CommonMarker and so it felt most natural to make the PR to this project.

@pyrmont pyrmont changed the title Remove square brackets from HTML output of footnotes. Remove square brackets when rendering HTML for footnotes Mar 12, 2018
@gjtorikian
Copy link
Owner

My hunch says this should go into the upstream github/cmark repo, because that's where this logic lives.

@kivikakk I'm actually not sure, why do we have both a submodule to upstream, as well as all the C files in the ext directory?

@kivikakk
Copy link
Collaborator

I would love to get this fix into the upstream repo! This would be the most effective fix, since the HtmlRenderer is only used sparsely.

re: both submodule and C files, the submodule is used exclusively for fetching the latest upstream source files for copying into the commonmarker repo itself. The files that are collapsed into ext/commonmarker are buildable without CMake; see #60.

@pyrmont
Copy link
Contributor Author

pyrmont commented Mar 12, 2018

Great! It looks to me like the upstream repo needs changes made to html.c and extensions.txt. I'll submit a PR.

@kivikakk
Copy link
Collaborator

Have pushed the submodule update to this branch!

@kivikakk kivikakk merged commit d834edf into gjtorikian:master Mar 12, 2018
@kivikakk
Copy link
Collaborator

This is in commonmarker 0.17.9, now on RubyGems!

@gjtorikian
Copy link
Owner

Would a gitignore of the individual C files in this repo make sense? Basically I want to avoid the situation where someone comes in and edits one of the pulled-out-of-upstream files.

@kivikakk
Copy link
Collaborator

I don't mind that idea, though it screws with the way the Makefile (per cmark-hs) works to update and include only the correct .c and .h files from the upstream — it relies on the appropriately-named files already existing in ext/commonmarker to know which ones to update from the upstream.

It might be an idea to just explicitly name every source file instead, though there's 64ish of them.

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

3 participants