Re: [Zim-wiki] new wiki syntax: better way to implement in Zim ?
On Sat, Jan 29, 2011 at 2:51 PM, Thorsten Hackbarth thorsten.hackba...@gmx.de wrote: I experimented with replacing zim's Parsetree with docutils.document class. I think I would prefer not to replace the ParseTree structure (although it is due some refactoring). Main reason is that this structure is fine tuned for the interfaces the zim code needs. To leverage usage of docutils a converter of zim's structure to docutils structure can be used to export data or reversed for import. No need to make zim use the docutils structure natively throughout the code. -- Jaap ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] new wiki syntax: better way to implement in Zim ?
Hi, I experimented with replacing zim's Parsetree with docutils.document class. The docutils/reStructueredText approach looks quite promising: - the code looks well structured - and its documented - there are writers for different formats. (latex, odt,...) - positive side effect: parsers/writers for new formats could expand the docutils code base but a lot of work: - I could not find a (working) rst writer !? - for compatibility it's necessary to write a docusils parser for zim wiki syntax - maybe expand zim to support all rst markup features Regards, Thorsten ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] new wiki syntax: better way to implement in Zim ?
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.pngwidth=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
Re: [Zim-wiki] new wiki syntax: better way to implement in Zim ?
Hi Ecaroh, hi everybody. I don't understand the difference you make between ascii markups and wiki markups, what can be called Lightweight markup language (http://en.wikipedia.org/wiki/Lightweight_markup_language) ; for me, markdown is a wiki markup, as Dokuwiki syntax, pmwiki syntax, mediawiki syntax, asciidoc, reStructuredText, creole, etc, are. **But i get your point** as i have quit the same needs. I worked with markdown syntax a couple of years ago, before defining my own syntax and the tools to convert / generate it (in PHP). Now, there could be 2 different approaches in Zim : - Giving Zim the ability to work with multiple wiki syntaxes - Enhancing the export fonctionality to be able to convert zim notebook pages in other wiki syntaxes The 2 options are not exclusives. For a lot of my work done with other softwares or with other formats, i wrote some converting tools (http://omacronides.com/projets/pyrnb/#converters). But now i want to work with Zim (because it's a wonderful tool). So, what i try to do is to be able to choose the wiki syntax used in a zim notebook when you create it. And once you have a Parser / Dumper for one specific format, building a export functionality can be easy. (I'm also working on a template chooser, but that's for another thread). I have a solution that works, but it needs a couple of enhancements (i'm a java|PHP|javascript developer, not python, so it takes me some time to find the right way to code things). If Jaap considers that the code can be useful, he could merge it into the Zim trunk. If not, i will publish a public release with those modifications, and maybe it could suit your needs. More in the days to come. BTW, i find the wiki creole approach very interesting too. Regards -- Rui Nibau Développeur web, rédacteur scientifique email : rui.ni...@omacronides.com jabber: rui.ni...@omacronides.com site : http://omacronides.com pgp : http://omacronides.com/services/pgp-public-key/ signature.asc Description: This is a digitally signed message part ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] new wiki syntax: better way to implement in Zim ?
On Fri, Jan 28, 2011 at 3:12 PM, Rui Nibau rui.ni...@omacronides.comwrote: - Giving Zim the ability to work with multiple wiki syntaxes - Enhancing the export fonctionality to be able to convert zim notebook pages in other wiki syntaxes As I understood it, Jaap said that the official Zim syntax is the etree with the tags Zim uses, and additions to import/export to/from that format are welcome. I already wrote in Python a parser for Zim-wikitext that I think is easy to extend. I'm waiting only for a formalization of the etree and for a minimal plugin system (headers are good enough for import, but What about export?) -- Juancarlo *Añez* ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] new wiki syntax: better way to implement in Zim ?
Hi everybody. So, my first try was a complete mess ! Well, the new wiki syntax worked, but it was poorly integrated into Zim ! I changed a couple of things, and you can see how it goes now here : http://omacronides.com/media/videos/zim/zim-new-wiki-syntax-01.ogv - When you create a new notebook, you can choose which wiki syntax to use. - wiki syntax is a property of the notebook. - syntaxes list is built with the python files starting with 'wiki' in the formats module (quite messy). - default is wiki, means the Zim wiki syntax Regards -- Rui Nibau Développeur web, rédacteur scientifique email : rui.ni...@omacronides.com jabber: rui.ni...@omacronides.com site : http://omacronides.com pgp : http://omacronides.com/services/pgp-public-key/ signature.asc Description: This is a digitally signed message part ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] new wiki syntax: better way to implement in Zim ?
On Sun, Jan 23, 2011 at 2:50 PM, Rui Nibau rui.ni...@omacronides.com wrote:
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 think this should be a notebook property, as different notebooks may
have different default syntax. As such it could be in the notebook
properties dialog. Using a commandline option is not really the right
way, because that would not work when zim is called e.g. from the
desktop application menu. As for coding style I would not use a
parameter WIKI_SYNTAX in all capitals as that suggests a constant,
while in this case this will be a configuration parameter.
To make things more complicated you might want to think about pages
that do not follow the default. The zim text files have a heading that
gives the wiki format. Ideally for other formats these headings should
still be there but now tell the notebook what alternative syntax they
use. THis would mean the default syntax is only used explicitly when
creating a new page.
However I realize that having these headers may conflict with the
existing wiki implementation with which you want to interface. For now
it will work to just use the default when no headers are present.
However the discussion in this bug report may change that :
https://bugs.launchpad.net/zim/+bug/705479
So apart from a module for parsing the format you may also need to
subclass the store/files.py module to fine tune it for your specific
file layout.
If you put the code you have so far in launchpad we can discuss more
specific how to implement this.
Regards,
Jaap
___
Mailing list: https://launchpad.net/~zim-wiki
Post to : zim-wiki@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zim-wiki
More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] new wiki syntax: better way to implement in Zim ?
On Sun, Jan 23, 2011 at 4:29 PM, Juancarlo Añez apal...@gmail.com wrote: If Jaap could refactor the code so Wiki parsers were pluggable and had a defined pluging API, some of us would be really happy. As I understand the current state of affairs, the spec for the output of a wiki parser is the source code for current parser, of which Japp talks of as 'hacked'. I would like to nuance that statement a bit. The parser is hacked in the sense that it doesn't follow a specific standard design. However the interface is quite clear and separated from the parser implementation. We use the xml.etree module to create XML object structures which are used internally to represent text formatting. Agreed that detailed documentation is lacking a bit but have a look at HACKING/Parse_Tree.txt in the source package. Or look at the unit tests for the parser, where this intermediate XML is used extensively. There is a builder class in zim/formats/__init__.py that can help to construct the XML object tree. As for being able to plug in new formats. Currently the the only way is to install a new module in the zim/formats namespace. The get_format() module will then pick it up. If there is a need to add formats from other namespaces we can easily add a method for plugins to register additional modules. Regards, Jaap ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] new wiki syntax: better way to implement in Zim ?
On Mon, Jan 24, 2011 at 3:52 PM, Svenn Are Bjerkem svenn.bjer...@googlemail.com wrote: ... 8 ... Now I wonder what the motivation is to have additional markup language support in zim? Main argument is to use zim in combination with other software like an existing online wiki or existing text-to-html tools. Maybe it will not match as nicely with zim's features as the default syntax. But should be possible if there is a strong enough use case for people creating the parsers. ... 8 ... Many markup languages have comment commands which does not show up in the rendered text. If I could add a comment // zim: no-touch to the beginning of all my asciidoc files and zim would look for that before it decides to include it in its structure, I would be happy. This won't help for external files that I decide to put inside the domain of zim, but most of the text files in my structure are made by me. At the moment, I solve by using a different extension, but that sometimes give the fileview plugin a tough time when I try to open with an external application, as some extensions are assigned to specific applications. You are describing a reversed version of how I want to do it. By excluding any text files that do *not* have the zim header from the index we achieve the same result and without touching other file formats. -- Jaap ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] new wiki syntax: better way to implement in Zim ?
On Sun, Jan 23, 2011 at 9:20 AM, Rui Nibau rui.ni...@omacronides.comwrote: 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 ? If Jaap could refactor the code so Wiki parsers were pluggable and had a defined pluging API, some of us would be really happy. As I understand the current state of affairs, the spec for the output of a wiki parser is the source code for current parser, of which Japp talks of as 'hacked'. -- Juancarlo *Añez* ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
