[Request] Markdown syntax support

Sure, if someone is willing to write a parser module for it we can add it. For importing it needs to read markdown and put it in a zim specific XML-like tree structure. For complete read-write support we need both a parser and a dumper (see zim/formats/wiki.py for an example).

Apart of the parser the rest of zim operates on the tree structure and is agnostic about the exact wiki syntax being used.

Why not to use the existing module of Python named 'markdown'?
I think it would be best to provide one of following options:
(1) a switch button to change your view between markdown code and markdown parsed code
(2) dual-view mode with live parsing

For performance issues an alternative implementation should be preferred.
Take a look at: http://code.google.com/p/python-markdown2/source/browse/trunk/lib/markdown2.py

On Sun, Jan 16, 2011 at 1:43 AM, Benjamin Weber
<email address hidden> wrote:
> Why not to use the existing module of Python named 'markdown'?
> I think it would be best to provide one of following options:
> (1) a switch button to change your view between markdown code and markdown parsed code
> (2) dual-view mode with live parsing
>
> For performance issues an alternative implementation should be preferred.
> Take a look at: http://code.google.com/p/python-markdown2/source/browse/trunk/lib/markdown2.py

One of the key design principles of zim is to edit the formatted text
directly. A dual view interface would break the experience.

-- Jaap

Already commented over here https://bugs.launchpad.net/zim/+bug/526034, advocating for (in the case of markdown support), the value of adherence to Pandoc's extensions.

Regarding the importance of WYSIWYG editing, that is not at all important to me personally relative to the usefulness of the underlying data structures and ability to use Zim as one interoperable element in an open toolchain for managing documentation.

But that's me, FOSS developers do scratch their own itches. . .

For IMO a great example of striking the right balance, have a look at Python journaling app Rednotebook - it makes use of Txt2tags syntax and even the "Edit" view does some nice "most of the way" formatting for "Live" editing feedback when you've missed a syntax detail. . .

I agree that Markdown syntax should be supported, and actually replace the current DokuWiki based syntax. Here are some reasons:

* MarkDown is much more wide-spread and well-known
* MarkDown syntax is usually easier to type, e.g. *bold* instead of **bold**
* MarkDown's syntax is closer to the way people format "ASCII" text anyway
* MarkDown was developed for being both easy-to-read and easy-to-write, so fits very well with Zim's collapsed edit/view mode
* MarkDown is better supported as a source language by Pandoc
* MarkDown has mechanisms for escaping for special characters

See also http://hiltmon.com/blog/2012/02/20/the-markdown-mindset/ and http://512pixels.net/markdown-new-word51/ for why and how people are using MarkDown as a universal tool anyway.

See also https://bugs.launchpad.net/zim/+bug/946229 why mechanisms for escaping user input are important.

On Sun, Mar 4, 2012 at 6:35 PM, Christoph Zwerschke <email address hidden> wrote:
>
> I agree that Markdown syntax should be supported, and actually replace
> the current DokuWiki based syntax. Here are some reasons:
>
> * MarkDown is much more wide-spread and well-known
> * MarkDown syntax is usually easier to type, e.g. *bold* instead of **bold**
>
> * MarkDown's syntax is closer to the way people format "ASCII" text anyway
> * MarkDown was developed for being both easy-to-read and easy-to-write, so fits very well with Zim's collapsed edit/view mode
> * MarkDown is better supported as a source language by Pandoc
> * MarkDown has mechanisms for escaping for special characters

Yes all excellent arguments. But please explain how to deal with
features that are missing in markdown.

See the discussion here:
http://groups.google.com/group/pandoc-discuss/browse_thread/thread/7b13743028bc5932/813ac3c57bf9832d?lnk=gst&q=zim#813ac3c57bf9832d

Open issues & questions:

A) How to deal with underline / mark formatting ? Now rendering as
bold, which is acceptable for the time being

B) How to deal with indented paragraphs in zim ? Now ignoring any
indenting, because it would turn paragraphs into verbatim in markdown

This is a very difficult one to solve, since the "indent for verbatim"
rule markdown makes it completely incompatible with any natural syntax
for normal indented paragraphs.

Note that zim made the same mistake early on, but we fixed it by
introducing quotes for verbatim. I don't imagine we could convince the
whole markdown community to do the same ?

C) How to deal with image properties, like setting width and height ?

D) How to deal with with tags (and in the future anchors) ? For now
will just put them in as plain text

E) How to deal with inline objects ? (This is a future feature being
tested, allows plugins to do custom rendering for a block of data.)
Probably can re-use syntax for verbatim with code highlighting
properties - e.g. ask to highlight as "x-zim-plugin-foo". This will be
transparent as verbatim text if not supported.

In summary: the zim syntax was designed specifically to support zim's
feature set, markdown is not. Supporting markdown for export is one
thing. But using it as native format means it needs to be compatible
with all zim features.

Forgive me for my ignorance, but couldn't we just extend markdown with our own "extra" features?

Also, if I'm not mistaken, markdown has the ability to use html also. So for things outside the spec, like image properties, we could use html for that.

If it were me, I would start with "CommonMark," then extend it a little and maybe contact the CommonMark folks to see if we can get some new markup added to CommonMark.

Extended markdown syntax in replacement of the zim syntax would be great.
And no need to have code/rendered view when you can have both in the same time (see uberwriter: http://uberwriter.wolfvollprecht.de)

Just for you to know:

https://github.com/Xunius/markdown2zim

"Convert a text file written in markdown or zim wiki to the other."

About the discussion: for me is ok to use current Zim syntax as the default one for the reasons you said, as I think that could be nice to let users to choose Markdown from a plugin as said tlvince. It could facilitate Markdown users to start using Zim.