... goes on to name one tool (pandoc) that parses Org-Mode (and also parses Markdown. I would in fact guess pandoc is used much more often for the latter than the former).
> Org-Mode Has Excellent Tool Support
> this is not an article about Emacs
... goes on to describe the "tool support" in Emacs. Sorry, but the paragraph title here really implies we're going to be talking about a range of tools, not just Emacs.
And then to conclude:
> With this blog article I wanted to point out the usefulness of Org-mode even when you are not using Emacs as an writing tool.
Can anyone point me to where exactly in the article the author has done this?
Org-Mode is great if you use Emacs. Try installing the Org-Mode addon in your non-Emacs IDE of choice, and you'll hit the same "partially implemented/not-yet-supported/etc." issues you would using an obscure markdown parser. In this regard, Markdown is much more "standardised" than Org-Mode—a standard exists for both, but the level of adherance to that standard in terms of the total number of parsers out there is undoubtedly higher for Markdown.
I actually started using orgmode completely outside of Emacs.
The beginning workflow was VS Code, and I certainly appreciate your note about the partially implemented featureset of most orgmode non-Emacs clients.
I then discovered Orgzly (http://www.orgzly.com/) which I hooked up to VS Code using Drop Box free. Orgzly is fantastic and supports a lot more of orgmode than most clients. (edited to add: orgzly is an android app)
Now, however, I've dropped VS Code in favour of Emacs running on either Windows 10 or OS X terminals. There's a decent cheat sheet (https://orgmode.org/orgcard.pdf) that I refer to a lot.
So my advice would be to give orgmode a try using Orgzly at first, then get a simple instance of Emacs going and use the cheat sheet to make things easier to learn and dip into. I think the push to try to do things outside of Emacs is throwing away the orgmode original codebase baby with the Emacs bathwater. I know Emacs is considered scarier even than vim, but for my simple use case it works well. It was even fairly easy to get the org-jira plugin working to pull my Jira tickets into TODO items.
I think you have made several incorrect statements.
I love Markdown, but Org does a lot more, because:
* It supports a variety of timestamps, which is critical for implementing task management workflows. In fact, I think Org has more users for it's time management features than for anything else.
* It supports tables with spreadsheet-like formulas. So you can include data in your documents and perform computations. This opens the door to accounting, billing and part lists when doing project management, etc.
* It extends Emacs outline-mode, so it has a really consistent hierarchical structure, properties, tags and whatnot. Very important in a number of use cases.
* It supports literate programming, which I don't use, but can reasonably replace Jupyter-like notebooks.
* It defines a number of link types, which can be extended. Out of the box, it does support DOI for example. Which is important for many people doing reference management.
Org-mode looks very similar to markdown. Almost so that I would call it pointlessly different.
The word standardization gets abused a lot in our industry. Usually it implies something that 1) has a non ambiguous specification, 2) is widely used. 3) is endorsed by some standards body or cross industry organization or simply so widely used that it effectively is a standard 4) has multiple independent implementations (tools, parsers, websiters, etc.)
Org-mode has a specification (https://orgmode.org/); is at this point in time not widely used; has not been endorsed or proposed to a standards body like e.g. w3c, ietf, etc.; has a very limited amount of implementations. Declaring it a standard is meaningless until that is fixed.
The Github flavor of markdown has a decent specification (https://github.github.com/gfm/), many implementations of e.g. parsers for different languages, many websites/tools/etc. using it. It's not at this point a formal standard but the previous makes it more or less a de-facto industry standard that is widely used, with a reference OSS implementation and many other parsers aiming to be compatible.
If you are implementing markdown support, you could do worse than pick this flavor. Several other flavors are equally well specified, have similarly good tool support and industry endorsement, and might very well be considered standards in their own right.
Of course, like with Json, there's a long tail of not so great parsers that have implementation specific bugs/quirks/omissions/features, etc.
I don't really like opinions such as yours, because you're nitpicky.
This article actually doesn't give it justice, because Org-Mode is more than an alternative to Markdown because it specifies formatting for time-based tasks, so you can specify deadlines and you can also track the time you work on those tasks. You can use Org-Mode for task management in a way that other formats are not suitable.
Examples of tooling:
1. GitHub can render Org-Mode files (in gists, etc)
2. you can find task management tools for iPhone / Android that can work with Org-Mode, one example being: https://beorgapp.com/
> Org-Mode Makes Sense Outside of Emacs
> Org-Mode Has Excellent Tool Support
> this is not an article about Emacs
I honestly believe that org-mode alone is reason enough to keep emacs installed on your system. It's full-featured enough that you could ignore everything else Emacs does and still find it a very powerful application.
> the level of adherance to that standard in terms of the total number of parsers out there is undoubtedly higher for Markdown.
Sure, there is less tooling because it is used less, but that's not an argument against embracing it. The more people who use it, the more parsers will get written for it.
Last I looked into it (mainly with interest for vim), few if any parsers/tooling exist for it outside of emacs; as I recall, people claimed that it apparently has sufficient (undocumented/poorly specified) quirks in the emacs implementation that 100% reproduction is difficult; similar to implementing vim-mode for editor plugins
In which case, its only as standardized as the one implementation; which is exactly how standardized markdown started with (the perl implementation)
The authors argument that Markdown should be discarded because there are several competing implementations isn't valid.
For many years (even now), we have several competing implementations of HTML, yet the HTML document is the dominant presentational document format (and UI layout language). It hasn't done anything to hurt adoption.
The fact that Markdown does have a common subset of features, and that Markdown is widely interoperable with a vast amount of products is why it wins. As far as I can tell Org-Mode markup is used within Emacs and really nowhere else.
The argument isn't that Markdown is bad because there are competing implementations. The argument is that Markdown is bad because there is no standard for those implementations to adhere to, so they end up being wildly incompatible. With HTML, there will be browser differences, but there's a pretty well-defined standard which browsers try to adhere to; there will be bugs, but at least you can know you're writing standards-compliant HTML, and then work around particular browser engines as necessary.
You say Markdown has a common set of features, but what is that common set? There's no standard, and I find myself surprisingly frequently struggle with figuring out what's the correct way in a particular markdown engine to do what I need to do.
An example is that in Reddit's markdown; this text:
```
if (true) {
console.log("hi");
}
```
will all end up as inline code, with all the newlines and extra whitespace stripped out. The correct way to do it in Reddit's markdown is to hit the space bar (n+1)*4 times before each line, where n is the indentation level. Some (but presumably not all) other markdown engines would render it as a code block.
Markdown engines are also wildly inconsistent about when they treat something as a link, and whether they require a blank line between a paragraph and code blocks or lists.
They seem to mostly agree about how explicit links and bold and emphasis and headings work though, so if that's your consistent common set of features, I suppose you're right.
It's arguable that the fact that there are multiple implementations is itself a sign of success. If Org-Mode was to become widely adopted, it's pretty much inevitable it would get multiple implementations too.
HTML has a lock-in because it's supported by web browsers directly, exactly like JS. I have a profound dislike for anything SGML-related but what can I do? Display my website as a PDF? At best I can transpile an other format into HTML.
HTML and JS have succeeded in spite of their clunkiness, not because of it.
Markdown on the other hand has no such lock-in, mainly because it usually gets transpiled into HTML or other formats. Replacing it is a lot easier and can be done incrementally without client support.
The several competing implementations of HTML are not a feature, they are a complication we have to deal with. This has not hurt adoption because of the nature of the marketplace.
The 'number of implementations' issue with org-mode is that there are almost no implementations outside of Emacs. Standardization by obscurity is not a very compelling virtue, and the opportunity for widespread adoption has passed.
After considering two or three dozens of different "lightweight" markup languages (i.e. not flavors) and designing a few (plus at least three failed attempts to improve Markdown), I'm now almost convinced that Scribble [1] or Perl POD [2] have one of the best possible designs. Not that they are optimal, but they are definitely heading at the correct direction.
They are extremely generic: every Scribble syntax is prefixed `@`, every POD construct is either `letter<...>` or `=word`. And yet they are surprisingly unobstructive and readable enough. Compare with BBCode, which is also pretty generic but too annoying.
They are readily extensible and need no special one-off syntaxes for most things. Yes, using asterisks or underscores for emphasis is handy, but how about strike-throughs? Underlines? Non-emphasis italics (e.g. species name)? Language tags? Abbreviations? Do they nest? Do they work in any context? Why not adding some harmless options to the existing constructs? Syntax extensibility should be one of the foremost concerns of markup language design and they got it right.
Edit: I should stress that these concerns are only valid for writings. For casual comments, less is better (ideally no-follow links and verbatim texts should suffice).
As much as it pains me, org-mode is no better than Markdown when it comes to standards or implementations. There's basically just one de facto implementation of it, and it has no specification or standard. There are parsers out there, but all of them are lacking one or more of the parts that make org-mode so great. Markdown shines with its simplicity, org-mode shines with its extensibility. Want to use it like a Jupyter Notebook? No problem. Want to use it as a spreadsheet? No problem. Want to write academic papers and export it to LaTeX? No problem. Want to use it outside of Emacs? Well...
I've been looking for and at solutions for using org-mode as the markup language for a static site generator, and none of the ones I find do what I want. org-mode has a builtin exporter that can build whole websites, but it is very barebones. The only real solution I know of is Hakyll with Pandoc, which is what I'm playing with right now.
I wish we had something like CommonMark for org-mode, but the overlap of people who use org-mode and don't use Emacs is probably extremely small, so it's not like there will be competing implementations outside of Emacs.
>I've been looking for and at solutions for using org-mode as the markup language for a static site generator, and none of the ones I find do what I want.
I do exactly this via Pelican. I wrote a Pelican plugin to handle org files. Behind the scenes, it merely uses pandoc to convert to rst, and Pelican handles rst quite well.
No major issues so far. Email me if you want the code.
Note that my solution assumes one org file per post. I've been working on an equivalent of ox-hugo[1] for Pelican, and I can share that as well. It's still in alpha (I break compatibility all the time) - but it works well enough that I'm using it as my primary way of writing posts. Having all your posts in one org file is fantastic.
It's still the same concept - it extracts a subtree into an org file, and uses pandoc to convert to rst.
Sorry, probably missing something obvious: what prevents you from using Emacs instead of pandoc to convert Org to HTML in whatever pipeline you have going already?
The day org-mode will reach the masses is when the tutorials about it do not even mention the word emacs. Until then, it will inevitably be seen as a thing useful only for emacs users.
The day jazz will reach the masses is when the reviews about it do not even mention the word "black".
It's created by emacs users, for emacs users, it should absolutely mention that word everywhere and stress its origins, it's already widely adopted and who really cares if somebody who is so superficial that he rejects a superior solution because it originated in a text editor he doesn't like doesn't use it?
Last I checked, and admittedly it's been a while, parsing full org-mode syntax outside Emacs itself is a nightmare. It's essentially cloning whatever version of org-mode you have in mind.
Not that org-mode's any less for it. I'm no longer a daily user, but I was, for quite some time, to organization a particularly chaotic episode of my work life.
I really, really, really like org-mode. I've used it for more than a decade. I've written self-published books with it. I use it for capturing ideas. For writing Reveal presentation slides. My database of links. I use it as a lightweight kanban board for personal projects. I use it for generating technical documentation mixing graphs, code, and prose.
But most of that isn't possible without Emacs.
As a markup format I wish it was more widely used. The promise of org-mode is that text is the best format for storing your data in. However to properly read more than the surface markup language of org-mode requires a significant amount of software. And very few editors or software packages exist outside of emacs work with it.
And so lacking any other features of org-mode it's markup language isn't any more impressive or useful than any other and is more of a matter of preference. It would be nice if more software packages supported the org-mode markup syntax but I wouldn't say it's the most "reasonable," even given the arguments in this article.
Org mode is simply awesome and the only reason I open emacs these days. I still haven't managed to find a software, free or paid, which has the same amount of flexibility.
I recently came to the same conclusion as the article but was dismayed by the performance of the popular Vim plugin (and wasn't ready to switch to emacs), so I wrote a very, very minimal implementation which is enough to get me headings, folding, tables (including formula solving, the syntax for which is currently left as an exercise for the reader), unordered lists, dates, and various other things.
It's very much a work in progress (in particular, the syntax files expect a graphical Vim) but it's definitely improved my note-taking. Requires Python 3 support.
While reading the thing I could not help but feel like what I'd call "sensible markdown" is both very close and bijective to org syntax. The trouble comes when I need to define what is "sensible markdown" which is a thing I never attempted to do, but pragmatically works very well. It seems like it's CommonMark + GFM (for tables, checklists, and syntax-aware fenced code blocks mostly) + MarkdownLint[0], the latter enforcing stringent rules that makes Markdown very consistent and portable as well as prune the nonsensical stuff (like double space before newline or underline headings). It's fantastic to use with VScode[1] or vim-ale.
Some pet peeves:
I really don't ever get the argument about Markdown URLS. Being able to do both [](url) vs [][ref] is awesome (the latter I liberally use when writing long form docs). If one finds it so annoying one would make the mistake like three times and then it'd be burned into one's brain due to selective pressure. Or just use [][ref] style (which is more readable anyway since you don't have the URL right in the middle of a sentence).
Also, very personal thing but my brain seems to hate /italics/ as it branch predicts into parsing that as a regex.
What drives me nuts though is all the variants and ad hoc syntaxes like JIRA's or this very board's, which sit right in the uncanny valley of nonsense.
Gak, yeah, I empathize. JIRA was a pain point for me too.
I take comprehensive notes using org-mode (including all of my false turns, dead ends and "explore this later"s) and when I need to paste something into a ticket I export via ox-jira.el and copy/paste what I need. It works much better than the author's modest README might lead you to believe, and of course it's hackable.
To date, I haven't seen a flavor of Markdown that has a comment feature. I use it extensively to hide all my notes that don't have a place in the final exported document people will read.
AsciiDoc! As nice as org-mode syntax, but with "=" instead of "*". Also, has code blocks so copy&paste is nicer. Also, has one giant document explaining everything.
My first love was AsciiDoc and it still is. I never got into markdown as much as AsciiDoc because it did what I wanted which was to generate documentation for software. However, when keeping track of stuff I am working on, snippets of possible code and completion status, etc. then Org-Mode has my attention. I have tried doing the same in markdown but most themes don't handle TODO as gracefully as ones targeting org-mode.
I agree. My experience with asciidoc is that it's much more comprehensive and straightforward than trying to manage all the competing markdown implementations while still maintaining legible syntax and a full feature set
I use org-mode often. It's a very intuitive way of structuring notes because most things are hierarchical in nature and lend themselves well to infinitely nested lists. It really pairs well with The LISP Way™️.
I use it to make flashcards (csv format for Anki) out of my notes. The front side is the hierarchy of a headline to its parents, and the back is the text below the headline.
e.g.,
* Python3
** I/O
*** modes
- 'r' open for reading (default)
- 'w' open for writing, truncating the file first
- 'x' open for exclusive creation, failing if the file already exists
- 'a' open for writing, appending to the end of the file if it exists
- 'b' binary mode
- 't' text mode (default)
- '+' open a disk file for updating (reading and writing)
However I would say that there are much better markup languages out there. (Or better yet, don't use a markup language at all and use richer formats. We're not in the PDP11 era anymore.) It's good if you need version control though.
It does look nice, and I'd be more than happy to put some effort and use Org-Mode, instead of Markdown, if only
- There was a standardized release outside emacs which would consistently provide the same results.
- There was an easy way to render documents (like the Perl script markdown has)
- There was serious support for plugins for my editor for easy rendering to pdf/html/whatever.
The author claims, several times, that "many" people use org-mode outside of emacs.
I am skeptical of that.
The whole point of an abbreviated mark-up is to RENDER that mark-up into something else. The "many" people who use org-mode outside of emacs are just a subset of pandoc commandline users (and perhaps some other tool which I am not even aware of). I guess it depends on what one considers to be "many"?
I can't help but think this is a bit more of an apples-to-oranges comparison than it's being treated as in this post. Org's introduction (chapter 1.1 of its manual) begins,
* Org is a mode for keeping notes, maintaining TODO lists, and project planning with a fast and effective plain-text markup language. It also is an authoring system with unique support for literate programming and reproducible research.*
Whereas the introduction to Markdown from its original author begins simply,
Markdown is a text-to-HTML conversion tool for web writers.
These are both lightweight markup languages, sure, but they're designed for different domains. What makes Org-mode interesting isn't ultimately its markup language; look at all the comments here talking about tasks and tags and such. What makes it interesting is its implementation. Markdown, conversely, was explicitly intended as an HTML preprocessor. You can do anything in Markdown that you can do in HTML for the simple reason that if you can't do it in Markdown, you can literally use HTML. That's not what Org-mode is for.
I think the thesis of this article is basically "Org-mode's specific choices with respect to markup syntax are better than Markdown's." And, well, fine; I'm not entirely sure I agree, but I'm not sure it really matters. What does matter to me is that Markdown (a) works very well for what I want in practice and (b) works everywhere I want it to. If I was one of the folks who lived in Emacs, the chances are Org-mode would handily hit both of those points for me. But I'm not. And as lucideer noted in his comment, just because it's possible to use (a subset of) Org-mode's markup outside Emacs doesn't mean it offers any particular advantage over, well, Markdown.
Once I played with tables in org-mode, I never turned back to markdown. I am not sure if there is another markup tool which looks at tables as good org-mode does.
[+] [-] lucideer|7 years ago|reply
... goes on to name one tool (pandoc) that parses Org-Mode (and also parses Markdown. I would in fact guess pandoc is used much more often for the latter than the former).
> Org-Mode Has Excellent Tool Support
> this is not an article about Emacs
... goes on to describe the "tool support" in Emacs. Sorry, but the paragraph title here really implies we're going to be talking about a range of tools, not just Emacs.
And then to conclude:
> With this blog article I wanted to point out the usefulness of Org-mode even when you are not using Emacs as an writing tool.
Can anyone point me to where exactly in the article the author has done this?
Org-Mode is great if you use Emacs. Try installing the Org-Mode addon in your non-Emacs IDE of choice, and you'll hit the same "partially implemented/not-yet-supported/etc." issues you would using an obscure markdown parser. In this regard, Markdown is much more "standardised" than Org-Mode—a standard exists for both, but the level of adherance to that standard in terms of the total number of parsers out there is undoubtedly higher for Markdown.
[+] [-] bloopernova|7 years ago|reply
The beginning workflow was VS Code, and I certainly appreciate your note about the partially implemented featureset of most orgmode non-Emacs clients.
I then discovered Orgzly (http://www.orgzly.com/) which I hooked up to VS Code using Drop Box free. Orgzly is fantastic and supports a lot more of orgmode than most clients. (edited to add: orgzly is an android app)
Now, however, I've dropped VS Code in favour of Emacs running on either Windows 10 or OS X terminals. There's a decent cheat sheet (https://orgmode.org/orgcard.pdf) that I refer to a lot.
So my advice would be to give orgmode a try using Orgzly at first, then get a simple instance of Emacs going and use the cheat sheet to make things easier to learn and dip into. I think the push to try to do things outside of Emacs is throwing away the orgmode original codebase baby with the Emacs bathwater. I know Emacs is considered scarier even than vim, but for my simple use case it works well. It was even fairly easy to get the org-jira plugin working to pull my Jira tickets into TODO items.
[+] [-] nextos|7 years ago|reply
I love Markdown, but Org does a lot more, because:
* It supports a variety of timestamps, which is critical for implementing task management workflows. In fact, I think Org has more users for it's time management features than for anything else.
* It supports tables with spreadsheet-like formulas. So you can include data in your documents and perform computations. This opens the door to accounting, billing and part lists when doing project management, etc.
* It extends Emacs outline-mode, so it has a really consistent hierarchical structure, properties, tags and whatnot. Very important in a number of use cases.
* It supports literate programming, which I don't use, but can reasonably replace Jupyter-like notebooks.
* It defines a number of link types, which can be extended. Out of the box, it does support DOI for example. Which is important for many people doing reference management.
[+] [-] jillesvangurp|7 years ago|reply
The word standardization gets abused a lot in our industry. Usually it implies something that 1) has a non ambiguous specification, 2) is widely used. 3) is endorsed by some standards body or cross industry organization or simply so widely used that it effectively is a standard 4) has multiple independent implementations (tools, parsers, websiters, etc.)
Org-mode has a specification (https://orgmode.org/); is at this point in time not widely used; has not been endorsed or proposed to a standards body like e.g. w3c, ietf, etc.; has a very limited amount of implementations. Declaring it a standard is meaningless until that is fixed.
The Github flavor of markdown has a decent specification (https://github.github.com/gfm/), many implementations of e.g. parsers for different languages, many websites/tools/etc. using it. It's not at this point a formal standard but the previous makes it more or less a de-facto industry standard that is widely used, with a reference OSS implementation and many other parsers aiming to be compatible.
If you are implementing markdown support, you could do worse than pick this flavor. Several other flavors are equally well specified, have similarly good tool support and industry endorsement, and might very well be considered standards in their own right.
Of course, like with Json, there's a long tail of not so great parsers that have implementation specific bugs/quirks/omissions/features, etc.
[+] [-] bad_user|7 years ago|reply
This article actually doesn't give it justice, because Org-Mode is more than an alternative to Markdown because it specifies formatting for time-based tasks, so you can specify deadlines and you can also track the time you work on those tasks. You can use Org-Mode for task management in a way that other formats are not suitable.
Examples of tooling:
1. GitHub can render Org-Mode files (in gists, etc)
2. you can find task management tools for iPhone / Android that can work with Org-Mode, one example being: https://beorgapp.com/
3. in a text editor all you really need is syntax highlighting, but yes, you can find plugins for many editors, not as evolved as Emacs's, but acceptable, e.g. https://marketplace.visualstudio.com/itemdetails?itemName=to...
Speaking of apps like no. 2, show me TODO apps that synchronize text files to Dropbox, using your format of choice that's not Org-Mode.
Is tooling really a reason for why you're not using Org-Mode, or is it because you're too conservative to try it?
[+] [-] schwartzworld|7 years ago|reply
I honestly believe that org-mode alone is reason enough to keep emacs installed on your system. It's full-featured enough that you could ignore everything else Emacs does and still find it a very powerful application.
> the level of adherance to that standard in terms of the total number of parsers out there is undoubtedly higher for Markdown.
Sure, there is less tooling because it is used less, but that's not an argument against embracing it. The more people who use it, the more parsers will get written for it.
[+] [-] setr|7 years ago|reply
Last I looked into it (mainly with interest for vim), few if any parsers/tooling exist for it outside of emacs; as I recall, people claimed that it apparently has sufficient (undocumented/poorly specified) quirks in the emacs implementation that 100% reproduction is difficult; similar to implementing vim-mode for editor plugins
In which case, its only as standardized as the one implementation; which is exactly how standardized markdown started with (the perl implementation)
[+] [-] JonAtkinson|7 years ago|reply
For many years (even now), we have several competing implementations of HTML, yet the HTML document is the dominant presentational document format (and UI layout language). It hasn't done anything to hurt adoption.
The fact that Markdown does have a common subset of features, and that Markdown is widely interoperable with a vast amount of products is why it wins. As far as I can tell Org-Mode markup is used within Emacs and really nowhere else.
[+] [-] mort96|7 years ago|reply
You say Markdown has a common set of features, but what is that common set? There's no standard, and I find myself surprisingly frequently struggle with figuring out what's the correct way in a particular markdown engine to do what I need to do.
An example is that in Reddit's markdown; this text:
will all end up as inline code, with all the newlines and extra whitespace stripped out. The correct way to do it in Reddit's markdown is to hit the space bar (n+1)*4 times before each line, where n is the indentation level. Some (but presumably not all) other markdown engines would render it as a code block.Markdown engines are also wildly inconsistent about when they treat something as a link, and whether they require a blank line between a paragraph and code blocks or lists.
They seem to mostly agree about how explicit links and bold and emphasis and headings work though, so if that's your consistent common set of features, I suppose you're right.
[+] [-] simonh|7 years ago|reply
[+] [-] simias|7 years ago|reply
HTML and JS have succeeded in spite of their clunkiness, not because of it.
Markdown on the other hand has no such lock-in, mainly because it usually gets transpiled into HTML or other formats. Replacing it is a lot easier and can be done incrementally without client support.
[+] [-] mannykannot|7 years ago|reply
The 'number of implementations' issue with org-mode is that there are almost no implementations outside of Emacs. Standardization by obscurity is not a very compelling virtue, and the opportunity for widespread adoption has passed.
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] tamrix|7 years ago|reply
[+] [-] lifthrasiir|7 years ago|reply
They are extremely generic: every Scribble syntax is prefixed `@`, every POD construct is either `letter<...>` or `=word`. And yet they are surprisingly unobstructive and readable enough. Compare with BBCode, which is also pretty generic but too annoying.
They are readily extensible and need no special one-off syntaxes for most things. Yes, using asterisks or underscores for emphasis is handy, but how about strike-throughs? Underlines? Non-emphasis italics (e.g. species name)? Language tags? Abbreviations? Do they nest? Do they work in any context? Why not adding some harmless options to the existing constructs? Syntax extensibility should be one of the foremost concerns of markup language design and they got it right.
Edit: I should stress that these concerns are only valid for writings. For casual comments, less is better (ideally no-follow links and verbatim texts should suffice).
[1] https://docs.racket-lang.org/scribble/
[2] https://perldoc.perl.org/perlpod.html
[+] [-] hollasch|7 years ago|reply
Write in any text editor, and a tiny JS boilerplate turns it into nicely-rendered HTML.
[+] [-] skullborg|7 years ago|reply
[+] [-] sondr3|7 years ago|reply
I've been looking for and at solutions for using org-mode as the markup language for a static site generator, and none of the ones I find do what I want. org-mode has a builtin exporter that can build whole websites, but it is very barebones. The only real solution I know of is Hakyll with Pandoc, which is what I'm playing with right now.
I wish we had something like CommonMark for org-mode, but the overlap of people who use org-mode and don't use Emacs is probably extremely small, so it's not like there will be competing implementations outside of Emacs.
[+] [-] BeetleB|7 years ago|reply
I do exactly this via Pelican. I wrote a Pelican plugin to handle org files. Behind the scenes, it merely uses pandoc to convert to rst, and Pelican handles rst quite well.
No major issues so far. Email me if you want the code.
Note that my solution assumes one org file per post. I've been working on an equivalent of ox-hugo[1] for Pelican, and I can share that as well. It's still in alpha (I break compatibility all the time) - but it works well enough that I'm using it as my primary way of writing posts. Having all your posts in one org file is fantastic.
It's still the same concept - it extracts a subtree into an org file, and uses pandoc to convert to rst.
[1] https://ox-hugo.scripter.co/
[+] [-] kqr|7 years ago|reply
[+] [-] enriquto|7 years ago|reply
[+] [-] mickael-kerjean|7 years ago|reply
[+] [-] sdwisely|7 years ago|reply
Without Emacs, org-mode is just weird markdown.
The way it can quickly link between different types of unrelated content just doesn't make sense outside Emacs.
[+] [-] nukeop|7 years ago|reply
It's created by emacs users, for emacs users, it should absolutely mention that word everywhere and stress its origins, it's already widely adopted and who really cares if somebody who is so superficial that he rejects a superior solution because it originated in a text editor he doesn't like doesn't use it?
[+] [-] kemitchell|7 years ago|reply
Not that org-mode's any less for it. I'm no longer a daily user, but I was, for quite some time, to organization a particularly chaotic episode of my work life.
[+] [-] agentultra|7 years ago|reply
But most of that isn't possible without Emacs.
As a markup format I wish it was more widely used. The promise of org-mode is that text is the best format for storing your data in. However to properly read more than the surface markup language of org-mode requires a significant amount of software. And very few editors or software packages exist outside of emacs work with it.
And so lacking any other features of org-mode it's markup language isn't any more impressive or useful than any other and is more of a matter of preference. It would be nice if more software packages supported the org-mode markup syntax but I wouldn't say it's the most "reasonable," even given the arguments in this article.
[+] [-] enitihas|7 years ago|reply
[+] [-] jeromenerf|7 years ago|reply
People complain a bit too much about productivity and context switching.
[+] [-] black-tea|7 years ago|reply
[+] [-] wzdd|7 years ago|reply
I recently came to the same conclusion as the article but was dismayed by the performance of the popular Vim plugin (and wasn't ready to switch to emacs), so I wrote a very, very minimal implementation which is enough to get me headings, folding, tables (including formula solving, the syntax for which is currently left as an exercise for the reader), unordered lists, dates, and various other things.
It's very much a work in progress (in particular, the syntax files expect a graphical Vim) but it's definitely improved my note-taking. Requires Python 3 support.
[+] [-] lloeki|7 years ago|reply
Some pet peeves:
I really don't ever get the argument about Markdown URLS. Being able to do both [](url) vs [][ref] is awesome (the latter I liberally use when writing long form docs). If one finds it so annoying one would make the mistake like three times and then it'd be burned into one's brain due to selective pressure. Or just use [][ref] style (which is more readable anyway since you don't have the URL right in the middle of a sentence).
Also, very personal thing but my brain seems to hate /italics/ as it branch predicts into parsing that as a regex.
What drives me nuts though is all the variants and ad hoc syntaxes like JIRA's or this very board's, which sit right in the uncanny valley of nonsense.
[0]: https://github.com/DavidAnson/markdownlint
[1]: https://github.com/DavidAnson/vscode-markdownlint
[+] [-] zwp|7 years ago|reply
Gak, yeah, I empathize. JIRA was a pain point for me too.
I take comprehensive notes using org-mode (including all of my false turns, dead ends and "explore this later"s) and when I need to paste something into a ticket I export via ox-jira.el and copy/paste what I need. It works much better than the author's modest README might lead you to believe, and of course it's hackable.
https://github.com/stig/ox-jira.el
[+] [-] mickael-kerjean|7 years ago|reply
To date, I haven't seen a flavor of Markdown that has a comment feature. I use it extensively to hide all my notes that don't have a place in the final exported document people will read.
[+] [-] bluenose69|7 years ago|reply
[+] [-] xamde|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] tmm84|7 years ago|reply
[+] [-] geogra4|7 years ago|reply
[+] [-] sandGorgon|7 years ago|reply
bunch of bindings - https://github.com/asciidoc , etc.
Also Oreilly publishing officially supports Asciidoc for Atlas publishing - http://docs.atlas.oreilly.com/writing_in_asciidoc.html
[+] [-] kqr|7 years ago|reply
[+] [-] zelly|7 years ago|reply
I use it to make flashcards (csv format for Anki) out of my notes. The front side is the hierarchy of a headline to its parents, and the back is the text below the headline.
e.g.,
...makes a flashcard like: source for undocumented spaghetti code: https://github.com/hackharmony/org-to-anki-csv/blob/master/o...However I would say that there are much better markup languages out there. (Or better yet, don't use a markup language at all and use richer formats. We're not in the PDP11 era anymore.) It's good if you need version control though.
[+] [-] tpaschalis|7 years ago|reply
[+] [-] crispyambulance|7 years ago|reply
I am skeptical of that.
The whole point of an abbreviated mark-up is to RENDER that mark-up into something else. The "many" people who use org-mode outside of emacs are just a subset of pandoc commandline users (and perhaps some other tool which I am not even aware of). I guess it depends on what one considers to be "many"?
[+] [-] chipotle_coyote|7 years ago|reply
* Org is a mode for keeping notes, maintaining TODO lists, and project planning with a fast and effective plain-text markup language. It also is an authoring system with unique support for literate programming and reproducible research.*
Whereas the introduction to Markdown from its original author begins simply,
Markdown is a text-to-HTML conversion tool for web writers.
These are both lightweight markup languages, sure, but they're designed for different domains. What makes Org-mode interesting isn't ultimately its markup language; look at all the comments here talking about tasks and tags and such. What makes it interesting is its implementation. Markdown, conversely, was explicitly intended as an HTML preprocessor. You can do anything in Markdown that you can do in HTML for the simple reason that if you can't do it in Markdown, you can literally use HTML. That's not what Org-mode is for.
I think the thesis of this article is basically "Org-mode's specific choices with respect to markup syntax are better than Markdown's." And, well, fine; I'm not entirely sure I agree, but I'm not sure it really matters. What does matter to me is that Markdown (a) works very well for what I want in practice and (b) works everywhere I want it to. If I was one of the folks who lived in Emacs, the chances are Org-mode would handily hit both of those points for me. But I'm not. And as lucideer noted in his comment, just because it's possible to use (a subset of) Org-mode's markup outside Emacs doesn't mean it offers any particular advantage over, well, Markdown.
[+] [-] fourier_mode|7 years ago|reply
[+] [-] joseph8th|7 years ago|reply
[+] [-] jopsen|7 years ago|reply
But adopting trumps perfection, hence, GFM is probably the most reasonable choice for new applications today.
[+] [-] 013a|7 years ago|reply
Let's be totally clear about this: If Org-Mode were actually popular, it too would have twelve variants. It is not popular.