[Windows] --syntax-definition thinks absolute file paths are protocols

[adamschoenemann]

If the --syntax-definition option is given an absolute windows file path, it will error with fatal error: unsupported protocol in URI. It seems to be thinking that there is a protocol specification in the path (presumably because of the colon). I could not find this error with a few other options (e.g. --output), which is strange. There is a repro here: https://github.com/adamschoenemann/pandoc-bug-repro

Pandoc version is 2.2.3.2

[jgm]

Your nonworking command is pandoc test.md --to=html5 -o test.html --syntax-definition=%cd%\test-syn-def.xml It would be more helpful to have a failing command where %cd% is filled in with its actual value. We have some code already that tries to distinguish between URLs and windows full paths, but it may need tweaking.

[mb21]

If this is an issue, I think it is actually in Skylighting, specifically: http://hackage.haskell.org/package/skylighting-core/docs/src/Skylighting.Parser.html#application

[jgm]

Ah yes. So, it's really readDocument from HXT that is throwing the error? If so, we probably can't do much about it, but one might ask the HXT maintainer. Mauro Bieg <notifications@github.com> writes:

…

If this is an issue, I think it is actually in [Skylighting](https://github.com/jgm/skylighting), specifically: http://hackage.haskell.org/package/skylighting-core/docs/src/Skylighting.Parser.html#application

[adamschoenemann]

Thanks for a taking a look at this. Re. %cd% I did this since substituting with an actual absolute path would likely throw an error regardless since you're unlikely to have checked out the repro repo at the exact same absolute path as I have. cmd should replace %cd% with your current working directory.

Anyway, @mb21 is most likely right about it being specific to Skylighting and therefore HXT. I'll see if I can get time to investigate more on the HXT side and open an issue there.

[jgm]

I don't see anything we can do about this on our end. You could submit an issue to https://github.com/UweSchmidt/hxt.

The part of the code in question is Text.XML.HXT.Arrow.XmlState.URIHandling, which uses parseURIReference from Network.URI. As you can see, this is what is causing the problem:

Prelude Network.URI> parseURIReference "C:/foo/bar"
Just C:/foo/bar

We work around this problem in pandoc by using a special wrapper: see Text.Pandoc.Class:

-- | Specialized version of parseURIReference that disallows
-- single-letter schemes.  Reason:  these are usually windows absolute
-- paths.
parseURIReference' :: String -> Maybe URI
parseURIReference' s =
  case parseURIReference s of
       Just u
         | length (uriScheme u) > 2  -> Just u
         | null (uriScheme u)        -> Just u  -- protocol-relative
       _                             -> Nothing

HXT could do something similar to fix this problem.

[adamschoenemann]

Great, I'll write an issue on HXT. Thanks!

[jgm]

Great! If you could put a link to it here, that would be helpful.

[jgm]

HXT may no longer be an active project. Perhaps the solution is to rewrite this code in skylighting using conduit-xml or xml-light.

[jgm]

Or, simpler, just use readString instead of readDocument?

[jgm]

I think I found a simple fix in pandoc itself. Can you test? Not easy for me to test on Windows.

[econwang]

does not work on windows, also does not work with http links

[jgm]

@econwang can you give more information? You tested what version of pandoc, with what exact command, and what results?

[econwang]

@econwang can you give more information? You tested what version of pandoc, with what exact command, and what results?

pandoc --syntax-definition=F:\SLib\stata.xml -o test.html test.md
fatal error: unsupported protocol in URI "F:\SLib\stata.xml"
pandoc 2.4