zim-wiki team mailing list archive

[Ecaroh <lists@xxxxxxxxxxxxxxxx>]

Hi!

Please excuse, my posting is a little bit longer. It has some thoughts 
about markup languages in general and the problems that rise around 
them if you have to import and export the data from various languages 
and file formats. If you interested in read more below..

----

Thoughts about markup, import, storage, editing and exports
===========================================================

ZIM - why not?
--------------
I am not an developer. ZIM is really a very good desktop wiki. But at 
the moment i can not use it straight through. The main reason is that i 
already have a lot of ascii formated content in different markup 
languages and moreover will always have to integrate new information 
written in different markup languages which then have to be imported, 
stored, edited, and to be exported again. ZIM uses DokuWiki Syntax, 
which is not easy to convert to and from other formats - besides that i 
do not like the syntax too much. Over the past years i tried to get a 
solution for that but still had not found the right tool which solves 
the problem of migrating markup. Recently i found Pandoc and unoconv 
which addresses a lot of problems together with Markdown Markup 
Langauge and normal (OpenOffice) office documents.

The reason i still use Markdown is on the one hand pandoc with its 
outstanding capabilities of import and export, on the other the fact 
that i use Webgen with Markdown as website generator. So, reusing my 
documents in any place works like a charm as long as i use one markup 
straightthrough all documents. Markdown is yet the most versatile 
markup i know - from the point of handling imports and exports.


ASCII based markup - really interoperable?
------------------------------------------
After searching the internet for a common simple asci markup i found 
that nearly none is really interoperabel - too much different approaches 
for the same problem. 


Markup standards
-----------------

As a quick overview there are more then three *major* ascii 
formating "standards" which are used by a large number of users:

Ascii based Markup:
 - Markdown
 - Asciidoc
 - reStructuredText
 - UDO <http://www.udo-open-source.org/index.php?lan=en>
 - txt2tags

Wiki based Markups:
 - Quiet a lot, see www.wikimatrix.org


After the quick spreading of wikis the old fashioned ascii markups may 
stay in a niche of computer geeks. Wiki syntax is common to a lot of 
people.


A common wiki language aproach
------------------------------

The Creole Project adresses the problem for the wiki world and tries to 
settle a common standard for wikis and ascii markup. Maybe Creole could 
be a way out of the format mess because it tries to create a syntax 
which extracts the most common things of different wiki languages. See 
more on the Creole Project:

http://www.wikicreole.org/

A small syntax sheet is here:

http://www.wikicreole.org/imageServlet?page=CheatSheet%2Fcreole_cheat_sheet.png&width=340

and a listing of lightweight markup languages here

http://en.wikipedia.org/wiki/Category:Lightweight_markup_languages

Don't know whether you all know these websites, i found them usefull.


A wish - not only - for ZIM
---------------------------

So far, it might be helpfull to
a) use another markup and have an import possibility
b) use another Markup (Creole) instead of DokuWiki syntax in ZIM
   (i do not think that the ZIM Header is a problem)
c) ability to later convert the ZIM Data to another output format
   (this can be done through pandoc et al. as long as the inner 
   storage format is not DokuWiki)


Conclusion
-----------

However, if i have the possibilty to convert markup or can use another 
markup language by a configuration parameter or in the settings of my 
application, i would highly appreciate that, cause it makes my live 
easier. Or in other words, i prefer common interoperability in opposite 
to 20% more features of any language.


Thanks for your audience and patience, any comments are highly 
appreciated.

	Ecaroh


Am Sonntag 23 Januar 2011 schrieb Rui Nibau:
> Hi everybody.
>
> I worked a couple of hours on Zim code source to deal with a new wiki
> syntax Parser / Dumper.
>
> The Dokuwiki syntax (used in Zim) is quite good, but i have tons of
> texts written with my own wiki syntax (inspired by other syntaxes -
> you can see what it does here -
> http://omacronides.com/projets/syntaxe-wiki/) and i wanted to use Zim
> to edit / view those texts.
>
> I already have a PHP code that parse and write this kind of syntax,
> and i adapted it a bit to support some Zim format features (like
> headers at the beginning of a file). So i was at a point where i can
> edit a zim notebook with those php tools. The next step was to adapt
> Zim to be able to deal with files written with my own wiki syntax.
>
> My PHP Reader / Writer work quite differently than the wiki Parser
> and Dumper in Zim  ; i didn't try to translate this behavior in
> python (maybe I'll do that when i have more than a few hours), so i
> just took the native code (zim.formats.wiki.py) and adapt it with a
> couple of new regex.
>
> So Jaap, my question is : **how can i tell Zim to use my wiki format
> to read / write notebook files** ? Well, i understand how to do it,
> as my (local) branch of Zim now works with the new wiki syntax ; the
> real question is : **which is - in your opinion - the best way to do
> it** ?
>
> By now, i run Zim with a command line argument, i.e :
>
> 	./zim.py --wiki-syntax=mywiki
>
> The default syntax still 'wiki', and the value is stored in a
> WIKI_SYNTAX property in zim module ; next, i clear the 'optsdict' in
> the main method if the argument is present, update the WIKI_SYNTAX
> property and use it everywhere in the code where there is a call for
> the format - i.e.  get_format('wiki') became
> get_format(zim.WIKI_SYNTAX).
>
> I read the related bugs / evolutions in launchpad :
>
> https://bugs.launchpad.net/zim/+bug/338030
> https://bugs.launchpad.net/zim/+bug/495898
> https://bugs.launchpad.net/zim/+bug/526034
>
> I saw that maybe alternative syntaxes could be a new feature.  So, if
> you ever think about this evolution, did you think of a way to do it
> ? Is my way a valid solution ? Or this feature should be managed in a
> plugin, or with a field in the preference dialog ?
>
> As I said, my code is now working, and i could create a branch in
> launchpad to share the code once a valuable implementation solution
> is defined.
>
> Thanks.