Can someone explain why this is useful? I thought the point of Markdown is that is easy enough on the eyes that you can comfortably edit the.source (and I certainly think it succeeds in that). Why would anyone abandone the comfort of their favorite editor to edit Markdown?
I'm looking for something kind of like this. Our company website is generated from Markdown, which is great for the devs on the team, but the marketing folks still struggle with it from time to time. So I'd really love to provide them with something that (1) forces UTF-8 on Windows, (2) eases writing in Markdown, and (3) shows the folder structure.
I'm currently setting them up with Sublime Edit, but it's not quite ideal as it's overly complex for what they need and I still have to manually configure it to default to UTF-8.
You can look at markdown et al. from another point of view: it's a file format that is human readable (text) and therefore "safe".
Many people care more about rendered markdown than about raw markdown, and would prefer to edit closer to the rendered result than to the human readable but not what they're interested in text. For those people, this eliminates the "write - render - check" cycle.
I don't even understand how wysiwyg can possibly apply to markup. Markup depends on a renderer for wyg. It could be PDF, plain text, HTML, RTF, XML, anything.
Looks good. Which gui toolkit are you using and do you embed pandoc? Which parts of markdown do you not support and are you planning support for other markup formats like AsciiDoc?
Thanks! UI is based on WebKit. Pandoc's license is GPL so I don't think I'll be embedding it.
As for Markdown parts – Texts 0.3 supports only blocks of plain text, headers (setext), unordered lists, code and math blocks (pandoc extension) and intervals of bold, italic, code, math and links. Only simple links (<URL>) are supported for now.
The idea is to expand syntax gradually, focusing on simplicity of user interaction. There are too many flavours of Markdown out there and several ways of writing the same structure in Gruber's Markdown is not a good thing, IMHO. There is no real need to decide between _italic_ and italic.
The object model of the text that is implemented is as simple as possible: blocks and spans (without nested spans). It shouldn't be a problem to implement essential parts of AsciiDoc and other plain text markups. When these formats get into the product depends on the interest from users. I'm planning to expose an API to allow implementation of formats as plugins.
You could "package" it by creating a separate component that's simply a pandoc process and have the two parts talk via one of the various serialization protocols on hackage (after all, web browsers need not be gpl just because the web server is). Itd be a shame to have to redo stuff that pandoc already does very nicely.
I am almost sure that this is covered by the gpl. Servers source code is protected because it is not distributed to the end user, not because there is some kind of a bridge between gpl code & your code.
Just from reading the web-site and looking at the images, I don't think it's clear enough as to what the editor does.
I presume you edit the document in the 'rendered' view (as opposed to the plain text), probably like in a word processor where apply formatting by selecting text and clicking buttons or pressing key-combos -- but I don't think there's anything there that clearly indicates that.
There's some degree of mixed-messages with the way in which it mentions/shows plain-text and markdown.
Thanks! Do you mean that menu options like "View as HTML", "View as PDF" etc. should process the current file with pandoc and display the resulting file?
The idea was to make Markdown accessible for those who don't want to learn the syntax.
But switching code block style (Cmd+3 on Mac or Ctrl+3 on Windows) on and off maintains inline syntax. So you can type raw Markdown into a code block and then switch it into plain text paragraph with formatting.
1) How do I make several levels of headers (#, ##, ###, ####)? This is what I use markdown for the most - nesting texts in clearly visible subsections. In the menu I can only see only one header, and in the screenshot I see two (==== and ---).
2) Rendering the PDF side-by-side would be useful. If I understood correctly one currently has to compile to PDF manually, which sort of defeats the purpose of a GUI app.
2) Yeah, it's "not implemented yet" :) Actually, there are many ways to publish from Markdown, including services like scriptogr.am. So I'm not sure that compiling PDF is the most important feature.
