-
-
Notifications
You must be signed in to change notification settings - Fork 7.6k
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
Asciidoc TOC stripped in 0.15 #1687
Comments
Duplicates in a way #1685. However, that particular issue about docs. |
I took a first look at the problem, and found some interesting twists. My first question is: The table of content (TOC) is generated within It turns out that AsciiDoc does not generate the TOC statically, but rather uses JavaScript to generates the TOC on-the-fly! With the I am happy to report, however, that Asciidoctor is not affected by this issue: Asciidoctor generates the full TOC as static HTML regardless of the
So, while we look at how to fix this issue #1687 in Hugo code, could you please install Asciidoctor and give it a try and see using Asciidoctor instead of AsciiDoc solves your problem? :-) Thanks! |
Hi Anthony, thanks for digging into this. We are using asciidoctor, however we were using 1.5.2. Switching to 1.5.3 (and Hugo 0.15), I could see the behaviour you described above: the ToC gets created in the HTML. Had to do some css changes to get it properly on the screen, but all now works as before. Sorry for your time spent on this - I should have checked if the asciidoctor version was the problem here before thinking it was a Hugo problem. |
Hi Joram, no need to apologize! In fact, thank you for bringing this to our attention. I would consider it (at least a partial) regression. And I didn't even know the older Asciidoctor 1.5.2 is affected too, and so is AsciiDoc (all versions), so definitely Hugo can check the program name and version too before choosing the right command-line flags. ;-) Oh! Indeed! Asciidoctor's ToC rendering behaviour is very new. From Asciidoctor's changelog entry for 1.5.3:
Thanks again! Re-opening this issue. Cheers, |
I would rather have |
Could be done? Sure. Will it? Probably not. |
Does it mean there is no way to get the |
A hacky workaround would be to use regular expressions. This is neither an elegant nor a performent approach but it should do the job. You can use the |
@digitalcraftsman Thanks for the suggestion. At this point, I will probably leave it for another time hoping a fix will come soonish. |
@anthonyfok what is the status of this? Any prospect of a fix? |
@anthonyfok what is the status of this? Any prospect of a fix? |
Fill the .TableOfContents template variable when writing Asciidoc content. This is done by letting Asciidoc render its TOC as HTML, then extract this HTML rendered TOC, parse it into a tableofcontents.Root and finally remove it from the HTML content. This aims to stay in the logic that the Asciidoc parsing is entirely done by the external helper. See gohugoio#1687
Fill the .TableOfContents template variable when writing Asciidoc content. This is done by letting Asciidoc render its TOC as HTML, then extract this HTML rendered TOC, parse it into a tableofcontents.Root and finally remove it from the HTML content. This aims to stay in the logic that the Asciidoc parsing is entirely done by the external helper. See gohugoio#1687
Fill the .TableOfContents template variable when writing Asciidoc content. This is done by letting Asciidoc render its TOC as HTML, then extract this HTML rendered TOC, parse it into a tableofcontents.Root and finally remove it from the HTML content. This aims to stay in the logic that the Asciidoc parsing is entirely done by the external helper. See gohugoio#1687
Fill the .TableOfContents template variable when writing Asciidoc content. This is done by letting Asciidoc render its TOC as HTML, then extract this HTML rendered TOC, parse it into a tableofcontents.Root and finally remove it from the HTML content. This aims to stay in the logic that the Asciidoc parsing is entirely done by the external helper. See gohugoio#1687
Fill the .TableOfContents template variable when writing Asciidoc content. This is done by letting Asciidoc render its TOC as HTML, then extract this HTML rendered TOC, parse it into a tableofcontents.Root and finally remove it from the HTML content. This aims to stay in the logic that the Asciidoc parsing is entirely done by the external helper. See #1687
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
See discussion thread here: https://discuss.gohugo.io/t/asciidoc-toc-stripped-in-0-15/2231
In 0.15, the TOC (table of con tent) of an asciidoc file is stripped away, while in 0.14 this wasn't the case. This is caused by this commit: b23b546. Would it be possible to make this hardcoded setting configurable?
The text was updated successfully, but these errors were encountered: