zim-wiki team mailing list archive

[HansBKK <hansbkk@xxxxxxxxx>]

Zim currently uses its own syntax, based on DokuWiki's. The author seems 
very interested in supporting a more standard syntax as an alternative, but 
(editorial aside 8-) is hampered in doing this within the app by a desire 
to keep WYSIWYG rather than a (modal?) edit/preview interface.

So to start with, he's apparently willing to consider writing an 
export/conversion routine out of Zim into one of Pandoc's input syntax 
formats and have users just use Pandoc from there to its many output 
targets. 

He may be reluctant to do learn enough Haskell to create a reader within 
Pandoc itself, but as long as he keeps up with extensions over time doing 
it from ?Python I think? should be equivalent, right?

The author (Jaap cc'd above) has asked me<http://lists.launchpad.net/zim-wiki/msg01511.html>to recommend the specific syntax - here is my reply, comments welcome, and 
most importantly let me know if I've got anything wrong.

---------- Forwarded message ----------
From: <hansbkk@xxxxxxxxx>
Date: Tue, Jan 24, 2012 at 10:16 AM
Subject: Re: [Zim-wiki] txt2tags support
To: Jaap Karssenberg <jaap.karssenberg@xxxxxxxxx>


Thanks so much for taking my supposedly-joking 
but-of-course-perfectly-serious-if-greedy requests in the right spirit.

On Tue, Jan 24, 2012 at 1:33 AM, Jaap Karssenberg <
jaap.karssenberg@xxxxxxxxx> wrote:

> On Mon, Jan 23, 2012 at 6:23 PM,  <hansbkk@xxxxxxxxx> wrote:
> > According to Wikipedia, but no where else I've found, Zim supports 
> exporting
> > to txt2tags.
> >
> > Was/is this (still/ever) true?
>
> This was true for the 0.2x series of zim. After the re-write in python I 
> didn't implement this again, and till today nobody complained about it. So 
> my guess is that not many people - if anybody - was using it.
>

Yes, txt2tags isn't as actively developed as other tools in the 
light-markup-documentation space and perhaps has lost some traction as an 
outbound-only source tagging format. I really like pandocs 
closer-to-any-to-any approach, and the developers are incredibly responsive 
to even the most niche requests if they seem potentially useful to anyone 
at all.
 

> Joking aside I had a look at the pandoc toolchain. Since it is haskell, it 
> is not something that is easy to adopt for zim. 


I wouldn't think there'd be any need to incorporate anything at the code 
level, as you say simply support the right syntax.
 

> However not having tried it I have no idea what format is best to support 
> for this kind of conversion: txt2tags, markdown, rest, .. ?
>

Pandoc and txt2tags have no conversion path to each other, only common 
target output formats, and as I said pandoc is deeper in several areas and 
IMO any important output format advantages t2 has will be taken up by 
pandoc RSN. For example, I personally think AsciiDoc is important as a 
light-markup alternative to full-blown DocBook XML. T2 outputs to that, but 
currently pandoc only outputs directly to the latter. However, someone has 
recently started working on an extension to pandoc to support the former as 
well.

To answer your question - the pandoc-extended flavor of markdown is its 
"native master source" syntax, and gets added to as various cross-platform 
features are extended - for example, currently being discussed in the list 
is the ability to apply span/divs for CSS purposes (of course this is 
html-only terminology, I forget the equivalent in LaTeX/PDF-speak) to 
inline "snippets" as well as block objects through something like this:

  - Here is some text and [this is the bit I want to receive a special 
style.]{.special_emphasis}.

However, reST/Sphinx is another well-supported "master source" syntax in 
Pandoc, and although not all of its directives are currently converted, I'm 
pretty sure the gaps are either unimportant, temporary or due to lack of 
equivalents in the target outputs.

The big advantage of reST is the very wide and deep support in the Python 
community, so working with that rather than pandoc's more "proprietary" 
flavor of markdown would give you a "two for one" benefit of attracting 
Pythonistas that may never have heard of pandoc, while still getting (I 
believe) 99% of the latter's functionality as well.

I will point out this thread to the pandoc guys and see if they agree with 
the above.