undefined method convert_xml_pi
settermjd opened this issue · 8 comments
While attempting to convert a Markdown file to Asciidoc with kramdoc, I encountered the following error. I thought it worth reporting, just in case it was unknown. I can provide a copy of the source file, if required.
Traceback (most recent call last):
14: from /usr/local/bin/kramdoc:23:in `<main>'
13: from /usr/local/bin/kramdoc:23:in `load'
12: from /Library/Ruby/Gems/2.6.0/gems/kramdown-asciidoc-1.0.1/bin/kramdoc:12:in `<top (required)>'
11: from /Library/Ruby/Gems/2.6.0/gems/kramdown-asciidoc-1.0.1/lib/kramdown-asciidoc/cli.rb:117:in `run'
10: from /Library/Ruby/Gems/2.6.0/gems/kramdown-asciidoc-1.0.1/lib/kramdown-asciidoc/api.rb:104:in `convert_file'
9: from /Library/Ruby/Gems/2.6.0/gems/kramdown-asciidoc-1.0.1/lib/kramdown-asciidoc/api.rb:52:in `convert'
8: from /Library/Ruby/Gems/2.6.0/gems/kramdown-1.17.0/lib/kramdown/document.rb:117:in `method_missing'
7: from /Library/Ruby/Gems/2.6.0/gems/kramdown-1.17.0/lib/kramdown/converter/base.rb:105:in `convert'
6: from /Library/Ruby/Gems/2.6.0/gems/kramdown-asciidoc-1.0.1/lib/kramdown-asciidoc/converter.rb:99:in `convert'
5: from /Library/Ruby/Gems/2.6.0/gems/kramdown-asciidoc-1.0.1/lib/kramdown-asciidoc/converter.rb:105:in `convert_root'
4: from /Library/Ruby/Gems/2.6.0/gems/kramdown-asciidoc-1.0.1/lib/kramdown-asciidoc/converter.rb:645:in `traverse'
3: from /Library/Ruby/Gems/2.6.0/gems/kramdown-asciidoc-1.0.1/lib/kramdown-asciidoc/converter.rb:645:in `each_with_index'
2: from /Library/Ruby/Gems/2.6.0/gems/kramdown-asciidoc-1.0.1/lib/kramdown-asciidoc/converter.rb:645:in `each'
1: from /Library/Ruby/Gems/2.6.0/gems/kramdown-asciidoc-1.0.1/lib/kramdown-asciidoc/converter.rb:646:in `block in traverse'
/Library/Ruby/Gems/2.6.0/gems/kramdown-asciidoc-1.0.1/lib/kramdown-asciidoc/converter.rb:99:in `convert': undefined method `convert_xml_pi' for #<Kramdown::AsciiDoc::Converter:0x00007fdcb00ac668> (NoMethodError)
Did you mean? convert_li
As you have probably concluded, this converter does not handle XML processing instructions. Though I'm sort of wondering how an XML processing instruction gets into a Markdown document.
It might be better to warn rather than crash when an unknown node is encountered.
Hi,
We encountered the same issue while migrating our markdown documentation into asciidoc.
Some of our documentation pages contain xml examples, it makes the conversion fail:
```xml
<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
<soap12:Body>
<CapitalCity xmlns="http://www.oorsprong.org/websamples.countryinfo">
<sCountryISOCode>${country}</sCountryISOCode>
</CapitalCity>
</soap12:Body>
</soap12:Envelope>
`` `
The workaround is simple, comment the xml in the md, convert it to asciidoc and then manage manually the xml example.
We had a similar issue with pages containing asciinema scripts meant to be interpreted later, but I guess this use case is less "legit".
<script type="text/javascript"> function loadCSS(filename){ let file = document.createElement("link"); file.setAttribute("rel", "stylesheet"); file.setAttribute("type", "text/css"); file.setAttribute("href", filename); document.head.appendChild(file); } loadCSS("./assets/asciinema-player.css"); </script>
<script src="./assets/asciinema-player.js"></script>
I have the same issue with XML in a fenced code block. Should it be processing the XML in a fenced code-block? Shouldn't it handle that as opaque textual data. I'm not an expert on this, but I wonder if this would be somehow exploitable (e.g. XXE injection or otherwise).
This does not occur with --format=GFM, but does with kramdown and markdown it is necessary to comment out the processing instruction, but the resulting code block is then mangled (though this might be a separate problem, as it doesn't occur with all fenced code blocks).
If someone wants to submit a PR to add support for processing instructions, I'm happy to review it.
Should it be processing the XML in a fenced code-block?
No, it definitely should not be. I'm unclear how this is happening. Perhaps it's something in Kramdown itself.
This does not occur with --format=GFM, but does with kramdown and markdown it is necessary to comment out the processing instruction
That's because the kramdown and markdown formats don't support fenced code blocks. So GFM is most likely what you want to use (and what most people consider to be true Markdown anyway).
I'm not able to reproduce this problem. I added a test to verify it works as expected. (See https://github.com/asciidoctor/kramdown-asciidoc/blob/main/spec/scenarios/codeblock/xml-with-pi.md). If you're able to reproduce this problem, please add a new scenario that demonstrates the problem.