5 ms·

I never understood the purpose of markdown editors. Isn't the main selling point that markdown is a human readable plain text format (i.e., vim will do/you don'

I never understood the purpose of markdown editors. Isn't the main selling point that markdown is a human readable plain text format (i.e., vim will do/you don't need preview)?

TazeTSchnitzel 10y ago
Theoretically. Unfortunately, Markdown has many potential ambiguities in interpretation, and unintuitive aspects.
- raimue 10y ago
  Especially for GitHub, I don't want to iteratively push commit after commit to README.md just to get the correct syntax for their GitHub-Flavored-Markdown. When editing on GitHub directly, I appreciate the preview to spot mistakes. However, there are many downsides of using the website for editing (like you can't combine changes to multiple files in a single commit). I prefer using a real editor locally, but using any other Markdown processor might give slightly different results. Therefore I use flavor [1] to filter the Markdown document through the GitHub API for reviewing it locally before pushing. [1] http://brettterpstra.com/2012/09/16/easy-command-line-github-flavored-markdown/ http://brettterpstra.com/2012/09/16/easy-command-line-github...
  - sevensor 10y ago
    Why not just use Pandoc with GFM syntax options?
    - raimue 10y ago
      flavor also includes CSS rules that closely resemble the design of GitHub, so I can view the result in my local browser as it would look on the GitHub website. With pandoc, I only get plain HTML output.
  - agateau 10y ago
    I wrote mup [1] to help with this: it is a markup previewer. It support multiple markup formats and for markdown multiple markdown implementations: pandoc, commonmark, kramdown, python-markdown and also previewing using GitHub API (slow but the most reliable for README.md editing) [1]: https://github.com/agateau/mup https://github.com/agateau/mup
  - anowlcalledjosh 10y ago
    grip (on pypi) is also pretty good, and can serve rendered HTML on its own.
- glenndebacker 10y ago
  That is why initiatives like Commonmark (http://commonmark.org/ http://commonmark.org/) exists.
anotheryou 10y ago
no. It is a semantically readable text document, that is easy to write and understand by humans too. It really shines when you do something with it after you wrote it (e.g. make a html and style it). I use it as a plain file/folder wiki and to have a future-proof format for the wiki.
- janpieterz 10y ago
  Interesting idea. Found it useful and working so far? Care to share (part) of your structure? I've always found wiki's and the like extremely difficult to organize. Lots of knowledge and little things, but it always runs out of hand quick.
  - anotheryou 10y ago
    It's an experiment and I'm trying to write all my notes in to it. The problem is the associative/ribosomal nature of information and the quickly missing context. We'd need to build a brain that gathers and understands context and files in all the cross-connections. Until google is done with that we are stuck with what's manageable: A hierarchy (folders) with some limited manual cross-links and full-text search. I'm using the yellow cms, with a wiki plugin: http://datenstrom.se/yellow/ http://datenstrom.se/yellow/ http://developers.datenstrom.se/edit/plugins/wiki-plugin/ http://developers.datenstrom.se/edit/plugins/wiki-plugin/ All running in a local http server. It's synced to my phone via Owncloud. On my phone I edit the plain files with JotterPad and sync with Foldersync. But I'm not super happy with yellow: - missing a tree view (I hacked together something but it's ugly) - special syntax for the title (but you can ignore it mostly) - special syntax for the wiki stuff - was difficult find the setting to change to .md file endings (bad/missing documentation) - requires an index.md in every folder What is really nice: i can drop a file in to a public version of the wiki and send a pretty link to someone.
adzm 10y ago
The other selling point is that you can use any/every editor you want, as long as it handles text. Sometimes it is helpful to use an editor with a live preview; other times it's preferable to use vim, or an ide.
- teamhappy 10y ago
  I get that if you have a lot of tables, images, etc. live preview is useful but I always shake my head when I open up a Github-style README in a text editor -- they're basically unreadable. Why not create an editor that outputs markdown that looks at least somewhat like a human wrote it (wrap lines at 80 columns, put links at the bottom, etc.)
  - frabbit 10y ago
    Agreed completely. An editor specialized to create human-readable Markdown would win my heart. Preview functionality is great, but a killer feature would be to make it easy to preserve the theoretical advantage of Markdown.

I never understood the purpose of markdown editors. Isn't the main selling point that markdown is a human readable plain text format (i.e., vim will do/you don't need preview)?

TazeTSchnitzel 10y ago

Theoretically. Unfortunately, Markdown has many potential ambiguities in interpretation, and unintuitive aspects.

raimue 10y ago
Especially for GitHub, I don't want to iteratively push commit after commit to README.md just to get the correct syntax for their GitHub-Flavored-Markdown. When editing on GitHub directly, I appreciate the preview to spot mistakes. However, there are many downsides of using the website for editing (like you can't combine changes to multiple files in a single commit). I prefer using a real editor locally, but using any other Markdown processor might give slightly different results. Therefore I use flavor [1] to filter the Markdown document through the GitHub API for reviewing it locally before pushing. [1] http://brettterpstra.com/2012/09/16/easy-command-line-github-flavored-markdown/ http://brettterpstra.com/2012/09/16/easy-command-line-github...
- sevensor 10y ago
  Why not just use Pandoc with GFM syntax options?
  - raimue 10y ago
    flavor also includes CSS rules that closely resemble the design of GitHub, so I can view the result in my local browser as it would look on the GitHub website. With pandoc, I only get plain HTML output.
- agateau 10y ago
  I wrote mup [1] to help with this: it is a markup previewer. It support multiple markup formats and for markdown multiple markdown implementations: pandoc, commonmark, kramdown, python-markdown and also previewing using GitHub API (slow but the most reliable for README.md editing) [1]: https://github.com/agateau/mup https://github.com/agateau/mup
- anowlcalledjosh 10y ago
  grip (on pypi) is also pretty good, and can serve rendered HTML on its own.
glenndebacker 10y ago
That is why initiatives like Commonmark (http://commonmark.org/ http://commonmark.org/) exists.

anotheryou 10y ago

no. It is a semantically readable text document, that is easy to write and understand by humans too. It really shines when you do something with it after you wrote it (e.g. make a html and style it). I use it as a plain file/folder wiki and to have a future-proof format for the wiki.

janpieterz 10y ago
Interesting idea. Found it useful and working so far? Care to share (part) of your structure? I've always found wiki's and the like extremely difficult to organize. Lots of knowledge and little things, but it always runs out of hand quick.
- anotheryou 10y ago
  It's an experiment and I'm trying to write all my notes in to it. The problem is the associative/ribosomal nature of information and the quickly missing context. We'd need to build a brain that gathers and understands context and files in all the cross-connections. Until google is done with that we are stuck with what's manageable: A hierarchy (folders) with some limited manual cross-links and full-text search. I'm using the yellow cms, with a wiki plugin: http://datenstrom.se/yellow/ http://datenstrom.se/yellow/ http://developers.datenstrom.se/edit/plugins/wiki-plugin/ http://developers.datenstrom.se/edit/plugins/wiki-plugin/ All running in a local http server. It's synced to my phone via Owncloud. On my phone I edit the plain files with JotterPad and sync with Foldersync. But I'm not super happy with yellow: - missing a tree view (I hacked together something but it's ugly) - special syntax for the title (but you can ignore it mostly) - special syntax for the wiki stuff - was difficult find the setting to change to .md file endings (bad/missing documentation) - requires an index.md in every folder What is really nice: i can drop a file in to a public version of the wiki and send a pretty link to someone.

adzm 10y ago

The other selling point is that you can use any/every editor you want, as long as it handles text. Sometimes it is helpful to use an editor with a live preview; other times it's preferable to use vim, or an ide.

teamhappy 10y ago
I get that if you have a lot of tables, images, etc. live preview is useful but I always shake my head when I open up a Github-style README in a text editor -- they're basically unreadable. Why not create an editor that outputs markdown that looks at least somewhat like a human wrote it (wrap lines at 80 columns, put links at the bottom, etc.)
- frabbit 10y ago
  Agreed completely. An editor specialized to create human-readable Markdown would win my heart. Preview functionality is great, but a killer feature would be to make it easy to preserve the theoretical advantage of Markdown.