zim-wiki team mailing list archive
Mailing list archive
Re: Zim (personal desktop wiki) looking to possibly support "pandoc syntax"
On Wednesday, January 25, 2012 3:41:49 PM UTC+1, HansBKK wrote:
> It turns out now there are actually three choices for your "entry point"
> syntax into Pandoc 8-)
> - markdown + extensions
> - a subset of standard reST (all the relevant bits)
> - json syntax
> John recommended reST based on the fact that Zim's a Python project.
> Pandoc supports all the reST features with corresponding markdown+
> elements, and I'm confident that support would expand if needed in the
> future (more on that below).
> I'm sure if you'd prefer markdown+ that would also work perfectly well,
> but note that reST is more of an "open standard" supported by the huge
> Python dev-docs community, while Pandoc's extensions are specific to Pandoc.
Understood. However since zim needs to convert data to it's own internal
structure in order to show it in the editor, I can not re-use existing
python code for reST. So no strong preference for reST over markdown as far
as I'm concerned.
And I will need a set of extensions anyway, because neither markdown and
reST support all markup types that zim has (things like strikeout,
subscript, superscript, etc.). Understood that extension will be less well
supported by other tools.
> I personally know very little about json (not being a programmer), but
> apparently that would most reliably represent the internal/native pandoc
> data structures; however its syntax isn't documented, so would require a
> fair bit of experimentation with pandocs itself.
JSON is not so much a format as a data structure. I can represent the
parsed text structure. Using this might help to avoid interpretation
differences between parsers. But that only works when the structure is
defined in a hard way. For now I think I will let this one rest.
In conclusion: I will try my hand on getting an export to markdown that
works with pandoc. In the coming months (long term plan) I'm working at
making zim use multiple formats as "native" formats (which has more
technical implications, than just import / export).