That's what I was wondering, donating or buying it eventually, will be good to write a note on donation, so people like me know what will be happening :)
Thanks! I just added a note below the download button.
- "Note: All the people who donated during beta will receive a license for free when Mou 1.0 released."
Very fine. I would suggest that you let the right pane follow the scroll position of the left pane (Or really - just have one scrollbar for them both). I know this isn't easy to accomplish, but it would really make a difference.
Doesn't say it on the page either until the very bottom.
It's almost as if it's a statement _not_ to say it upfront.
It transmits the unspoken assumption that you don't care about anything else or you don't expect your visitors to.
That's ridiculous. There's a screenshot at the top of the page; it's clearly on Mac OS X, and it isn't as if it claims to be a universal app for the whole planet. Personally I think if the page began with a giant "ONLY ON MAC OS X" disclaimer that would look more like he only cared about that.
It was just an oversight in the Hacker News post title which has now been corrected.
No, it isn't ridiculous. I've seen many projects available for multiple OS's that choose to advertise themselves with a Mac screenshot (or a Windows screenshot, or a Linux screenshot) at the top. The screenshot by itself says it runs on Macs, but doesn't establish that it's Mac-only; you need to read all the way to the bottom to make sure of that. It's disdainful of a non-Mac user; that may be accidental, but I've seen this more often on Mac product sites than on Win/Linux product sites.
Your "giant ONLY ON MAC OS X disclaimer" is a strawman; what would be normal and courteous is simply mentioning that it's for OS X somewhere at the top. There are many, many product sites that do it successfully (e.g. http://www.hogbaysoftware.com/products/writeroom).
The post title on HN is a separate issue that's actually less of a problem. A random link to a product on HN doesn't carry an implicit assumption that it'll run on my OS. I don't mind clicking on it and discovering it doesn't (and besides, the author can't control the text of a link that leads to their site). But when I need to scroll down five pages on the site to ascertain I can't actually use it, that's irksome.
Ah, right, thanks. Out of sheer lazyness of setting something up I generally use the built-in github editor and preview these days. It works pretty well.
I launched last week an online Markdown editor that works in all recent browsers (IE support not perfect yet but will be).
It does intelligent preview (the paragraph being edited is kept into view and highlighted), has autosave and a simple document manager that lets you export HTML or markdown (RTF coming soon), and also has a converter, to convert rich text TO markdown (for your legacy content).
Check it out! It's called "Akayame" for Yet Another Markdown Editor, at http://akaya.me
This is interesting but in my opinion, the layout and font size you choose ruins it. We should be able to see much much more text (raw and previewed) on a standard size screen.
Even worse, it ssays for Mac OS X Lion only (apparently according to the comments it should run in Snow Leopard). I'm quite sure an overwhelming majority of Mac OS users don't run Lion (in fact I know nobody running it ATM), and a significant part would rather wait for 10.8 because of all of 10.7 idiosyncrasies.
While it's probably not exactly what you're looking for, Safari's Snippet Editor is great for whipping up some quick HTML with auto preview. Accessible via the menu, Develop > Show Snippet Editor.
A while ago I wanted something similar and could not find it, so I decided to put this together http://jrmoran.com/playground/markdown-live-editor/. It has some minor bugs and I have not updated it in a while.
Looks pretty sweet. Markdown really is coming into a golden age, its everywhere: git readmes, stackoverflow posts, i'm even using it to write my presentations in these days! Love it :)
Looks great. Any chance you can make the line-height adjustable? I find the editor a little too squished.
It would also be useful if users could supply their own css for the preview rendering...that way you could see what it'll look like with your own stylesheet.
The scrolling needs some work as well. It seems as soon as I write anything, the preview just shoots back to the top. Ideally it would follow me as I type and the two would link up transparently and smoothly.
Those using MultiMarkdown[1], which this app seemingly doesn't support, may be interested in the MultiMarkdown Composer app[2] that should be out within a month or so. It's being worked on by the (very) active developer of MultiMarkdown and looks perfect for fans like myself.
That looks very nice, especially the TOC. I'd love to see it have a file-browser too similar to TextMate's, which is very nice if you like to organize MMD notes/docs in different files and folders.
Just a note, it'd be awesome if there was some way to specify the stylesheet used in the preview pane, I'd love to be able to see exactly how the result will look on my site.
I'm on snow leopard, so this might not be a bug as you said it runs on SL unofficially, but it's VEERY annoying that every time I edit the 'source' on the left, preview jumps up to the beginning and I have to scroll all the way down to where I was. This is unbearable for long articles.
I just have two small requests.
First, it seems you're using libdiscount (or objc bindings to libdiscount) to compile markdown, could you give the ability to pass flags to the compiler ? (e.g. activate footnotes).
Second but less critical to me, I'd love to be able to tweak the CSS of the generated page (less critical because I can just tweak the style.css file in ORCDiscount).
If Mou had those two (small) features I'd gladly donate/buy it when it comes out.
Thanks for this, I've been looking for a nice simple markdown editor that can kick out HTML for a while. I used to use TextMate's with it's Markdown preview, but since I stopped using TextMate I've needed something to fill that space. (Sublime Text 2 doesn't seem to have a preview feature)
Eclipse.org Aptana has a plugin for editing markdown, but i don't remember coming across a live preview feature. Usually use Dingus for preview http://daringfireball.net/projects/markdown/dingus so i'm gonna give this app a go in about 15m
Could anyone explain to me the trend to write HTML in some other markup syntax? I write HTML in HTML. Going from one markup language to another seems like an extra unnecessary prereq.
HTML is really verbose. I personally prefer HAML for my own stuff (it's like comparing the same doc in XML to YAML), but Markdown is definitely easy to read for programmers and non-programmers alike. Its intention is to read like a plain text email.
I would't say markdown is any easier to write because the verbosity of HTML tags and structure is usually taken care of with editor macros. It's definitely easier to read the source though.
Obviously web design work should be done in HTML, or a very close approximation thereof (HAML). However, despite the link title above, Markdown isn't a web design language at all. It's for writing and editing copy, which is a very different task.
Let's say you have a bunch of untrained writers who needs to do some semantic formatting. They don't know HTML, so you can't ask them to just write HTML. If you let them run rampant with a WYSIWYG word processor (probably Word) you'll wind up with monstrosities where fonts were manually bolded and enlarged to indicate headers and such, and someone has to clean up after it.
If you have Markdown editors, though, you can turn an untrained writer loose with a cheat sheet ("write # to get a header" and such) and you're all set. As a bonus, you can put the Markdown document in version control, export to formats besides HTML, and a few other useful things.
Some major websites like reddit have also successfully made use of Markdown and its competitors to permit rich text comments from people who know nothing about HTML.
Ideally, we would write everything in plaintext, but it doesn't support even the most basic features offered by typesetting (bold, italics, etc.) or hypertext (embedded links), so we turn to markup languages at the expense of readability.
Markup syntax like markdown, asciidoc, reStructuredText, etc. strive primarily to preserve readability with the least obtrusive syntax, and with a smaller learning curve (at least for the most basic usage).
So why use it instead of HTML? Like you, I typically write HTML in HTML, but often use asciidoc for other purposes (documentation, recipes, quick notes, etc.), because:
- One source document can output to multiple formats, like XHTML, LaTeX, PDF, DocBook, EPUB, Man page, etc. It's even trivial to output to a specific HTML DOCTYPE. That's pretty neat!
- Diffs are far more readable when not swimming in markup soup.
- HTML is overkill for many purposes. In fact, lightweight markup has its roots in email/newsgroup markup. HTML email is still a compatibility nightmare. Wouldn't it be great if a new standard for rich text email was developed, based on something as simple as markdown? It would be trivial to support it in webmail interfaces and the source would still be readable in plaintext email clients or if the sender went overboard with style choices.
- Archivability. Many old HTML documents render poorly in modern browsers, mainly due to style choices that seemed sensible at the time. Lightweight markup focuses more on the content and discourages going off on a stylistic tangent you may regret later. In other words, it does a good job of separating content from presentation, so your source documents will always remain readable and transform to something readable with relatively few tweaks in external stylesheets or configuration files.
Because it's easy to learn without getting lost in the arcane details of validation and compatibility, it's understandable why it's gaining popularity.
84 comments
[ 468 ms ] story [ 3828 ms ] thread:)
http://ethanschoonover.com/solarized
Why don't people add that to the title? It would prevent non-mac users from getting their expectations up.
It's almost as if it's a statement _not_ to say it upfront. It transmits the unspoken assumption that you don't care about anything else or you don't expect your visitors to.
It was just an oversight in the Hacker News post title which has now been corrected.
Your "giant ONLY ON MAC OS X disclaimer" is a strawman; what would be normal and courteous is simply mentioning that it's for OS X somewhere at the top. There are many, many product sites that do it successfully (e.g. http://www.hogbaysoftware.com/products/writeroom).
The post title on HN is a separate issue that's actually less of a problem. A random link to a product on HN doesn't carry an implicit assumption that it'll run on my OS. I don't mind clicking on it and discovering it doesn't (and besides, the author can't control the text of a link that leads to their site). But when I need to scroll down five pages on the site to ascertain I can't actually use it, that's irksome.
-jsl
http://sourceforge.net/p/retext/home/ReText/ http://www.webupd8.org/2011/05/retext-text-editor-for-markdo...
It does intelligent preview (the paragraph being edited is kept into view and highlighted), has autosave and a simple document manager that lets you export HTML or markdown (RTF coming soon), and also has a converter, to convert rich text TO markdown (for your legacy content).
Check it out! It's called "Akayame" for Yet Another Markdown Editor, at http://akaya.me
No syntax highlighting which is kind of a bummer.
http://i.imgur.com/omtFb.png
If possible, run it on Lion. :)
```
some code
```
It would also be useful if users could supply their own css for the preview rendering...that way you could see what it'll look like with your own stylesheet.
Custom css for preview rendering is already possible now. Simply edit the css file inside Mou's app bundle:
http://cl.ly/AaUT
But do backups first!
:)
[1]: http://fletcherpenney.net/multimarkdown/
[2]: http://multimarkdown.com/
http://cl.ly/AaUT
But do backups first!
:)
I just have two small requests. First, it seems you're using libdiscount (or objc bindings to libdiscount) to compile markdown, could you give the ability to pass flags to the compiler ? (e.g. activate footnotes). Second but less critical to me, I'd love to be able to tweak the CSS of the generated page (less critical because I can just tweak the style.css file in ORCDiscount).
If Mou had those two (small) features I'd gladly donate/buy it when it comes out.
https://github.com/vojto/markdownlive#readme
There're just too many comments and I can't watch this page minutes by minutes.
If you have questions or suggestions, please email me directly.
Thank you very much!
:)
I have no affiliation, just a happy customer. MacVim + Marked side by side is a neat combo.
Do others keep their final versions in Markdown?
I would't say markdown is any easier to write because the verbosity of HTML tags and structure is usually taken care of with editor macros. It's definitely easier to read the source though.
Let's say you have a bunch of untrained writers who needs to do some semantic formatting. They don't know HTML, so you can't ask them to just write HTML. If you let them run rampant with a WYSIWYG word processor (probably Word) you'll wind up with monstrosities where fonts were manually bolded and enlarged to indicate headers and such, and someone has to clean up after it.
If you have Markdown editors, though, you can turn an untrained writer loose with a cheat sheet ("write # to get a header" and such) and you're all set. As a bonus, you can put the Markdown document in version control, export to formats besides HTML, and a few other useful things.
Some major websites like reddit have also successfully made use of Markdown and its competitors to permit rich text comments from people who know nothing about HTML.
Markup syntax like markdown, asciidoc, reStructuredText, etc. strive primarily to preserve readability with the least obtrusive syntax, and with a smaller learning curve (at least for the most basic usage).
So why use it instead of HTML? Like you, I typically write HTML in HTML, but often use asciidoc for other purposes (documentation, recipes, quick notes, etc.), because:
- One source document can output to multiple formats, like XHTML, LaTeX, PDF, DocBook, EPUB, Man page, etc. It's even trivial to output to a specific HTML DOCTYPE. That's pretty neat!
- Diffs are far more readable when not swimming in markup soup.
- HTML is overkill for many purposes. In fact, lightweight markup has its roots in email/newsgroup markup. HTML email is still a compatibility nightmare. Wouldn't it be great if a new standard for rich text email was developed, based on something as simple as markdown? It would be trivial to support it in webmail interfaces and the source would still be readable in plaintext email clients or if the sender went overboard with style choices.
- Archivability. Many old HTML documents render poorly in modern browsers, mainly due to style choices that seemed sensible at the time. Lightweight markup focuses more on the content and discourages going off on a stylistic tangent you may regret later. In other words, it does a good job of separating content from presentation, so your source documents will always remain readable and transform to something readable with relatively few tweaks in external stylesheets or configuration files.
Because it's easy to learn without getting lost in the arcane details of validation and compatibility, it's understandable why it's gaining popularity.