Org-Mode Is One of the Most Reasonable Markup Languages to Use for Text (2018)(karl-voit.at)

518 pointsby funkaster7 lat temu245 comments

Org-Mode Is One of the Most Reasonable Markup Languages to Use for Text (2018)

https://karl-voit.at/2017/09/23/orgmode-as-markup-only/

250 comments

> Org-Mode Makes Sense Outside of Emacs

... 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.

bloopernova7 lat temu

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.

lucideer7 lat temu

> Now, however, I've dropped VS Code in favour of Emacs

I've tried on VS Code and also given up (on Org, not on vscode, which was far more central to my workflow than Org was).

I'd tried SyncOrg on Android, but had not heard of Orgzly. I see from your link it's on FDroid—just retried doing a search on FDroid for 'org-mode' to see what else is out there that I missed, and nothing comes up (neither SyncOrg not Orgzly). FDroid really need to fix their search, and/or makes of those clients really need to fix their metadata; not sure which.

I may give Orgzly a go, but tbh without decent desktop client (short of switching to Emacs, which I shan't be doing), I'm not sure how worthwhile it will be. I may try some pandoc automation...

bloopernova7 lat temu

> short of switching to Emacs, which I shan't be doing

I only use Emacs for org-mode stuff so far. For pretty much anything else I'm using VS Code.

If you're interested, the ~/.emacs file I use is at https://gist.github.com/anthonyclarka2/28543be1a5cbebd0d3d96...

dmix7 lat temu

Is the F-Droid apk search different than their website? It returns Orgzly in results for both "org-mode" and "Orgzly":

https://search.f-droid.org/?q=orgzly&lang=en

https://search.f-droid.org/?q=org-mode&lang=en

jhasse7 lat temu

Seems so. orgmode works in the app, but org-mode returns nothing.

4mitkumar7 lat temu

Orgzly is really grast in terms of feature support and minimalistic UI. I only wish it supported time logging as well, which I use fairly regularly.

Along with SyncThing and Emacs in laptop, that's my preferred organising system for the last 6 months or so.

wowtip7 lat temu

Does Orgzly work with Syncthing out of the box now? Last time I tried Orgzly it only used Dropbox for sync, which is what made me drop it at that time.

bloopernova7 lat temu

As far as I know, Orgzly still only works with Dropbox, which is a shame. I wish I had the programming skill to add that support, since Orgzly is open source.

However, Orgzly can sync with local directories on your Android device, so could Syncthing work via that route?

meko7 lat temu

Not sure what you mean by 'out of the box', but orgzly supports local directory syncing which can indeed be used in conjunction. Source: this is my setup.

nextos7 lat temu

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.

jmull7 lat temu

> I think you have made several incorrect statements.

If you're going to say that, you should list some of them (with corrections).

omaranto7 lat temu

Heck, even without corrections listing some would be way, way better than just claiming they exist.

lucideer7 lat temu

> I think you have made several incorrect statements.

If I did, I'd be eager to correct them. What were they?

> I love Markdown, but Org does a lot more

I agree. Org is great, as I said above.

I don't think I criticise Org anywhere in my comment, I was purely questioning the points in the article about non-Emacs use.

nextos7 lat temu

Apologies for my imprecise answer before.

I mainly intended to say I think Org is much more standardized than Markdown because there is at least a unique reference implementation and a unique reference document describing the format. Whereas for Markdown, you do have many slightly different implementations and attempts at standardization, despite Markdown being an order of magnitude simpler.

In places like GitLab, people are taking advantage of this by running Emacs in batch mode inside a container to effectively use the reference implementation for export-to-other-formats purposes.

It's not an ideal situation, though. And I hope someone creates a truly independent library. There is a Ruby parser employed by GitHub and GitLab which covers a decent subset of Org. Furthermore, Orgzly and vim-orgmode are pretty much closer to implementing a much bigger subset of Org.

lilyball7 lat temu

A reference implementation isn't standardization. Markdown had a reference implementation and yet subsequent implementations still diverged. The reference implementation also had bugs, which were fixed over time, thus changing the de-facto standard.

At this point, Markdown does have a real standard, CommonMark. GitHub-Flavored Markdown was modified to become an extension to CommonMark (it's literally just a few extra features on top of CommonMark at this point). There are of course non-CommonMark-based implementations still (such as MultiMarkdown) but at this point anyone adding Markdown support to a project should be using CommonMark or GFM.

pwinnski7 lat temu

There was a unique reference implementation for Markdown, too. It was ignored and extended by various popular services. If anybody fully implemented Org-mode outside of Emacs, it would likely have run into the same issue.

sachdevap7 lat temu

I think the solution is not just an implementation, but rather a language description independent of an implementation. A reference description would allow org mode format to be usable in perpetuity.

As a side-note: As a regular emacs and org-mode user, not a fan of the date format and lack of flexibility in picking repeating schedules.

jolmg7 lat temu

> not a fan of the date format and lack of flexibility in picking repeating schedules.

I haven't used repeaters that much, but I was under the impression that they were very, very flexible. At least much more flexible than a typical todo app. What don't you like about them?

For reference, here's some documentation about them:

https://orgmode.org/manual/Repeated-tasks.html

https://orgmode.org/manual/Timestamps.html#Timestamps

https://www.gnu.org/software/emacs/manual/html_node/org/Time...

https://www.gnu.org/software/emacs/manual/html_node/emacs/Se...

sachdevap7 lat temu

I am quite familiar with the available options for repeated entries. But Something as usual as 2nd Thursday of every month requires me to write a diary-float sexp, which is not intuitive to edit. If it is difficult to use for a programmer like me, I can only imagine how complicated it is for other people. Moreover, diary-float sexp expressions are most definitely not helping the argument of usability outside emacs.

jolmg7 lat temu

> But Something as usual as 2nd Thursday of every month requires me to write a diary-float sexp, which is not intuitive to edit.

I agree that it could be better, but I'd be surprised if it was something that was typically expressible in other programs. So the fact that it's doable at all seems great, and does indicate that it's flexible.

Since you said it lacked flexibility, I was wondering if you had an example of something that was not expressible in Emacs org-mode but that was expressible elsewhere.

> Moreover, diary-float sexp expressions are most definitely not helping the argument of usability outside emacs.

Well, it's not elisp, is it? It's just sexps. It may as well be JSON, but more concise.

sachdevap7 lat temu

Actually, Google Calendar does provide the choice of repeating every 2nd Thursday of every month. But it has its own limitation. For example, Google calendar does not let me do every 2nd and 4th Thursday of the month.

Just to clarify, I am not criticizing org-mode for not implementing in comparison to others. The lack of flexibility I suggest is the date format itself, which does not even allow specifying 2nd Thursday of the month for example. diary-float allows it, but is not intuitive.

I intend to write an interactive scheduling tool for org-mode when I can spare the time. Like regex-builder, but for dates.

jolmg7 lat temu

I was wondering just a while ago if it those diary syntaxes were really limited to sexps and wouldn't also evaluate arbitrary elisp and I saw this[1]:

  &%%(let ((dayname (calendar-day-of-week date))
           (day (cadr date)))
        (or (and (= day 21) (memq dayname '(1 2 3 4 5)))
            (and (memq day '(19 20)) (= dayname 5)))
           ) Pay check deposited

I don't know if this is doable from org-mode but it seems to me like this could be a viable, more readable alternative to diary-float.

For your example of 2nd Thursday from every month, instead of:

  %%(dairy-float t 4 2)

you could have:

  &%%(let ((day-of-week (calendar-day-name date))
           (day (cadr date)))
       (and (= day-of-week "Thursday")
            (> day 7)
            (<= day 14)))

That's seems more readable to someone that hasn't read what the parameters of dairy-float mean. For your second example of every 2nd and 4th Thursday:

  &%%(let ((day-of-week (calendar-day-name date))
           (day (cadr date)))
       (and (= day-of-week "Thursday")
            (or (and (> day 7) (<= day 14))
                (and (> day 21) (<= day 28)))))

It being a programming language might make it unintuitive to use by a non-programmer, but I don't think you can get anymore flexible than this. Also, org-mode's attractiveness being that everything is in plain text, I'm not sure there is a syntax that would be more readable than properly written code.

[1] https://www.gnu.org/software/emacs/manual/html_node/emacs/Se...

nextos7 lat temu

I'm not a super big fan of Org timestamps for dates, either. Flexibility is OK.

But I wish we had something like Remind [1] where you can define events based on e.g. Easter dates, skip recurring events if they fall into a holiday or move them according to a rule.

In particular, I hate I have to change all bank holidays every year. Remind got this right. There's some added complexity, though.

A nice thing about Org is the pragmatic way it deals with recurring events. You clone them and adjust at will, manually. So you can deal with really odd ways of re-scheduling meetings.

[1] https://www.roaringpenguin.com/wiki/index.php/Remind

sachdevap7 lat temu

Oh, that's an interesting point. Actually, for Easter [0], you could technically write a piece of code to figure out when Easter is. But on a more practical note, maybe Org-mode should have event based entries, which in my opinion also speaks to a lack of flexibility. It should be possible to anchor dates on other events, so you can have one annual calendar file to replace at once, which may be automatically generated. Like wanting to plan something a week before Easter?

[0] https://www.timeanddate.com/calendar/determining-easter-date...

nextos7 lat temu

Actually there's been an Elisp function posted to the Org mailing list to calculate Easter dates that has made it into the Org FAQ [1].

However, I'd prefer if all these things were merged into mainline.

[1] https://orgmode.org/worg/org-faq.html

jillesvangurp7 lat temu

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.

dewitt7 lat temu

> Org-mode looks very similar to markdown. Almost so that I would call it pointlessly different.

Just a minor note on this: Org-mode was created in 2003 (the syntax a bit earlier) and Markdown in 2004, so I think this was a case of parallel evolution, each unaware of the other, not intentional deviation.

Edit: And the use cases were different. Org was designed as a syntax for an outliner, and Markdown was designed as a syntax for prose. Both are plain text and optimized for readability in their pre-processed form, but maybe it's the fact that they are so similar that's remarkable.

leejoramo7 lat temu

In his original documentation for Markdown, Gruber acknowledges an number of influences. Mostly common plaintext email conventions of the time, but also Setext, reStructuredText, and more by name.

He did not include reference to org-mode, so he probably did not know of it at the time. (Although maybe Aaron Swartz was familiar with org-mode, and provided cross-pollination?)

Most likely as you mentioned, md and org both evolved independently from similar ancestors

https://daringfireball.net/projects/markdown/syntax

bitwize7 lat temu

The point is that as soon as one project looked like it was gaining critical mass, the other project should have conceded defeat and adopted the winning format. Because as we all know, the major problem with open source is there can be more than one of something.

Retra7 lat temu

They do not have the same features, and undoubtably the reason for that is because some users needed features the other doesn't have.

AsyncAwait7 lat temu

That is a ridiculous notion. People like myself escaped to free software in order to avoid the imposition of a vision by a single corporate entity, like you have with MS/Apple.

People are not uniform, they don't all like the same music, books etc. so why should this not be true for tools?

xj97 lat temu

you are implying that there is a standardized markdown flavor. pretty much every parser forks the "standard". even though markdown-ish is more common than org-mode, i don't think there is a clear winner here. common standards do emerge from open source, but we have to let the competition play out until the end. and tbfh, you aren't playing the game correctly if you just give up and die without overwhelming proof that your project in irrelevant.

snazz7 lat temu

Org-mode does fill the primary use-case for Markdown that I’ve seen, since GitHub will render it just like they do Markdown.

The small slice of Org-mode demonstrated in this article might look like just a Markdown clone, but within Emacs you can do things like a Jupypter notebook with Org-Babel, which GitHub renders statically. Granted, it’s possible to do these things without Emacs (or a watered down plugin for another editor).

heartofgold7 lat temu

Superficially org looks similar to markdown, but the kinds of manipulations you can do with TODO lists, calendars, tables within emacs is like magic. It's nothing like markdown when you use it this way.

_emacsomancer_7 lat temu

> Org-mode looks very similar to markdown. Almost so that I would call it pointlessly different.

Only at the very basic feature set of Org mode. But Org also allows for properties, and tags, and timestamps, and deadlines, etc. etc.

thekaleb7 lat temu

I would point out this as the standard without GitHub extensions: https://commonmark.org

jillesvangurp7 lat temu

Github flavor spec specifies it is a strict superset of that. But you are right to mention this.

throwanem7 lat temu

I agree that Org-mode and Markdown are pointlessly different! The latter has no excuse for existing, given that the former both long predates it in time and vastly exceeds it in power.

chipotle_coyote7 lat temu

> given that the former both long predates it in time

Org-mode's initial release was in 2003 (I can't find a specific month); Markdown's was in March 2004. So Org-mode predates Markdown by about a year. Personally, as someone who is not an Emacs user, I heard of Markdown years before I ever heard of Org-mode.

SmellyGeekBoy7 lat temu

One could say the same about Usenet and Hacker News. Yet here we are.

[deleted]7 lat temu

feanaro7 lat temu

No reason at all, except a robust, complete implementation not hopelessly tied to a particular editor.

bad_user7 lat temu

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/

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?

agentwiggles7 lat temu

Tooling is definitely at least part of why I don't use org, and I use emacs as my primary editor. I love the concept of org, but getting it synced and using it on mobile were not trivial, and features that I'd expect from any similar solution were all painfully manual. I wanted to love org, but I just haven't found a way to make it work for me, and tooling is certainly part of the problem.

schwartzworld7 lat temu

> 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.

setr7 lat temu

>org-mode is standardized

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)

terhechte7 lat temu

Came here just to say that. I had a static blog written in org-mode and converted it over to markdown a couple of weeks ago because there's no good way of converting org-mode to html except by running emacs. So for each article, getting a html representation requires firing up emacs. That's insane.

If there were good (and fast!) js, c, python, etc libraries to fully support parsing org-mode to AST and HTML, only then would it be a viable solution for markup.

s7atic7 lat temu

Emacs can run as an elisp interpreter, check out the '--script' switch. This makes it possible to run org-export without starting an emacs session.

kqr7 lat temu

I was just about to say. The GP sounds like they're saying

> there's no good way of converting <markup language> to html except by running <preferred converter>. So for each article, getting a html representation requires firing up <preferred converter>. That's insane.

terhechte7 lat temu

And how do I use that when I want to interactively convert org-mode to html in javascript? Like countless pure-javascript markdown libraries allow me to do? not to mention the security hazards of running emacs with any user input from a website.

kqr7 lat temu

That you don't – much like you don't get Pandoc Markdown in JavaScript, because Pandoc is not written in JS.

But if you are content with a less featured variation of the markup language (but still more featureful than Markdown), you can get that for JavaScript too: https://xiaoxinghu.github.io/orgajs/syntax

terhechte7 lat temu

And how do I use that when I want to interactively convert org-mode to html in javascript? Like countless pure-javascript markdown libraries allow me to do?

not to mention the security hazards of running emacs with any user input from a website.

yepguy7 lat temu

OK, but you just switched use cases from a "static blog" to interactive web page with untrusted inputs.

omaranto7 lat temu

First, pandoc does a pretty decent job of converting Org Mode to HTML or several other formats.

Second, "firing" up Emacs sounds odd to Org Mode's target audience. :) We already have Emacs open! (I typed this comment in Emacs).

I don't know how hard it is to make a nice looking website in Org Mode, but to make bland websites for academics (like this schmuck's page: https://www.matem.unam.mx/~omar/), I think Org Mode and org-publish are great. And probably it's not harder to make a nice website with org-publish than with anything else: the trick is being willing to learn CSS. :)

singingfish7 lat temu

Pandoc makes me extremely happy. My consultant wanted a .doc file the other day: `pandoc -f org -t support_brief.org -o support_brief.docx`

Of course the canonical format for pandoc is markdown.

omaranto7 lat temu

To be specific, the canonical format for Pandoc is Pandoc Markdown, which is still my favorite flavor of Markdown (I guess Github-falvored is my second favorite). But Org Mode is even nicer than Pandoc Markdown, so I used Pandoc to convert all my files to Org Mode.

zeckalpha7 lat temu

And Hakyll is a static site generator based on Pandoc, letting you leave your site source in whichever markup you choose.

rakoo7 lat temu

If you're turning markup formatted files into html there is pandoc (https://pandoc.org/) for that

zaiste7 lat temu

Kulfon [1] is a static site generator that compiles Org Mode to HTML without using Emacs. You can just drop `.org` files in a directory and run a one-command tool to make this work. I use it for my website, mostly to write blog posts. It is also possible to mix Markdown and Org Mode files in a single project/directory.

Kulfon is my own project, so take it with a grain of salt. I've decided to focus on Org Mode as I also believe this format doesn't get the recognition it deserves. It doesn't mean Markdown is bad, au contraire, it is almost perfect. In Org Mode, for instance, I still cannot get used to the source code blocks. It is, however, good to have a choice.

The Org Mode support in Kulfon is not perfect yet, but good enough for most situations. It is based on a JavaScript plugin by Xiaoxing Hu called orgajs [2]. You can use it directly in your project.

One of the motivations for building a SSG with Org Mode was Org Brain [3]. I have a plenty of interconnected notes that I would like to publish on my website « as-is ». This would be rather difficult to do using Markdown format.

[1]: https://kulfon.org/ [2]: https://github.com/xiaoxinghu/orgajs [3]: https://github.com/Kungsgeten/org-brain

TeMPOraL7 lat temu

That's a fair point. My own blog runs a two-step process: I export org-mode posts to HTML with Emacs/Org-Mode exporter, and then rewrite the result in my static generator.

sondr37 lat temu

Do you have a public repo for your blog? I couldn't find anything on GitHub.

TeMPOraL7 lat temu

Nah, the generator is so full of garbage code that I keep it as a private repo. The generator handles both new posts (org-exported to HTML) and old posts (Wordpress exports I dumped to org mode).

A partial snippet of the code that handles new posts:

https://gist.github.com/TeMPOraL/c401f12d50d4e1d4f94492e3d0f...

What's happening is that I take the HTML generated by Emacs Org Mode exporter, deserialize it to DOM, select a block corresponding to contents (to cut out superfluous stuff I don't need), and then run a bunch of tree-walkers that massages the DOM until it becomes something I can wrap with my site's scaffolding and dump into a file. It's really ugly, but gets the job done.

db48x7 lat temu

That eight megs of memory is a pretty terrible price.

melling7 lat temu

8MB fits in L3 cache these days.

Naac7 lat temu

Did pandoc not convert org files to HTML correctly?

ekns7 lat temu

Pandoc only handles a subset of org-mode markup.

IIRC last time I tried this (long ago) there were a number of gaps in things like org-mode tables.

At the limiting case, the (common or uncommon) elisp extensions (e.g. org-babel) will likely never be processed by third-party tools.

disgruntledphd27 lat temu

If you put the results of org-babel into the buffer, then pandoc handles everything OK.

The one problem I have with pandoc is that when using word export, it loses the table and figure numbers. Mind you, at least I only have to put those in outside emacs :)

otikik7 lat temu

> Pandoc only handles a subset of org-mode markup.

To me that's got the same drawbacks as "not standardized". If not all of the existing tools support the standard then there are several de facto standards.

nambit7 lat temu

Yeah. I use markdown hosted file and do the markdown -> html conversion entirely clientside via http://dynalon.github.io/mdwiki/#!index.md. I don't think it's possible to do that at all with orgmode?

BeetleB7 lat temu

I use Pelican for my static blog, and it takes both markdown and rst. I've automated the process: I convert org to rst using pandoc, and let Pelican take it from there. I literally made a Pelican plugin to do it - so my content directory now just has org files.

So far, I've not seen any major issues.

mruts7 lat temu

What’s wrong with pandoc? I use org-mode but only export with pandoc because it works better.

namelosw7 lat temu

Can confirm. I tried several libs in several languages to parse org there are always weird results.

Maybe Ruby's implementation is best for now since github is using it.

quanticle7 lat temu

Github's Ruby implementation of org-mode syntax has quite a few holes in it, as shown by this test page: https://github.com/novoid/github-orgmode-tests

JonAtkinson7 lat temu

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.

mort967 lat temu

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.

cfv7 lat temu

Commonmark (https://commonmark.org) exists, has a fairly well defined standard, and the reference implementations are not hard to reason about. They are part of several thousands of larger codebases right now, too.

Org-mode on the other hand is basically an emacs thing that has never been seen in the wild outside maybe as a pandoc input? Which is coincidentally another tool I almost never actually use by itself. And I have literally no idea how ota reference implementation works or on which languages could I embed it and how.

I'm pretty sure my experience isn't that rare too.

AlexCoventry7 lat temu

> an emacs thing that has never been seen in the wild outside maybe as a pandoc input

There are a couple of vim plugins. I don't know whether they're any good.

https://www.reddit.com/r/vim/comments/4ms4z0/org_mode_which_...

bachmeier7 lat temu

> Commonmark (https://commonmark.org) exists, has a fairly well defined standard

Commonmark didn't really accomplish much in terms of standardization. The problem is that they didn't take seriously comments that they didn't support everything they needed to support in order for it to be a standard. The most prominent example is support for math, which is extremely common. That wouldn't be so bad if there were support to escape processing, but they weren't willing to support that either.

The response is to tell anyone that they need to look for an implementation with the proper extensions for equations or whatever you might need that's not currently supported. There's not much to be gained from having a standard if it doesn't ensure document compatibility among competing implementations. Commonmark is nothing but yet another version of markdown.

inlineint7 lat temu

> 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.

There is CommonMark specification: https://commonmark.org.

mort967 lat temu

Yeah, CommonMark is awesome, and if the argument was about CommonMark and not Markdown in general, I'd be on the other side of the argument. However, most Markdown renderers don't implement CommonMark.

pitaj7 lat temu

Many of the most popular markdown renderers do implement CommonMark, though.

uranusjr7 lat temu

> 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.

This argument is valid, but…

> An example is that in Reddit's markdown; this text: [snipped] will all end up as inline code, with all the newlines and extra whitespace stripped out.

This does not validate the argument. Implementations defer to John Gruber’s Markdown Syntax Documentation.[1] It is insufficient to be used as a standard (hence your argument being valid), but does (in some cases) provide a common subset of features compatible everywhere. The “fenced” code block is not included in Gruber’s original Markdown, but became so popular due to GitHub that people come to expect it. It is still not part of “Standard Markdown” though.

[1]: https://daringfireball.net/projects/markdown/syntax

lucideer7 lat temu

Furthermore, GFM* has fast become a defacto standard for newer implementations—still a bit of incompatibility, but improving.

* GFM = Github Flavoured Markdown, even if Gitlab have very cheekily taken on the same initialism for their (in fairness, highly compatible) flavour.

xemdetia7 lat temu

Has anyone found a good GFM to HTML converter that does not call out to a SaaS service (often GitHub)? I keep ending up in use cases where I need to do this conversion or do a live preview without having the data leave the box. When I was looking around previously I found out that under the hood they were using the GitHub API to actually do the preview.

theandrewbailey7 lat temu

I've used marked for years, and it doesn't make any network calls. In fact, it looks like it does tons of regex.

https://github.com/markedjs/marked

tokyodude7 lat temu

there are lots of other issues. AFAICT HTML is allowed inline in markdown but the flowing inline HTML is interpretted differently depending on implementation

    some markdown text

    <div>
      some
      **inline**
      text
    </div>

    some more markdown text

some will take that as one block. some will process each line separately. some will convert the asterisks ...

laumars7 lat temu

HTML inlined into markdown is easily my least favourite feature of markdown. In my opinion it breaks the very point of of MD (namely that it's formatting makes as much sense in a graphical render as it does in a plain text editor).

0xbadcafebee7 lat temu

If Org-mode became widespread, it too would suffer from different implementations.

localhostdotdev7 lat temu

reddit's code formatting is its own story, it supports both 4 spaces and triple backticks (but only on redesign web).

> On redesign, a slightly-edited version of CommonMark. On old reddit, it's still snudown.

(and mobile apps have their own markdown)

> New Reddit note: Indented code blocks are the only form of code block that works on Old Reddit. Use them for compatibility

https://www.reddit.com/wiki/markdown#wiki_code_blocks_and_in...

maybe in a few years there is going to be syntax highlighting, one can hope :) (slack doesn't have it either, but even discord has it...)

curioussavage7 lat temu

I did some investigation into this recently. My hope is to make at least new reddit support it this year. Can't promise anything about old.reddit.com though

davemp7 lat temu

It doesn't help that there's no unambiguous CFG for Markdown. Any new implementation is more or less on their own with many using odd tricks to get around the inherent ambiguity.

simonh7 lat temu

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.

mgoetzke7 lat temu

indeed it is. When something is used by a lot of people, they will find use cases not covered sufficiently and will try to extend. Some of these will survive and be absorbed back, some will not. Normal evolutionary pressure at work.

simias7 lat temu

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.

mannykannot7 lat temu

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.

[deleted]7 lat temu

tamrix7 lat temu

And so soon we'll get org-mode to markdown transpilers.

mickael-kerjean7 lat temu

We've been having it since quite a few years, it's called export and it looks like this:

- original org: https://demo.filestash.app/api/export/hnorg/text/org/emacs.o...

- markdown: https://demo.filestash.app/api/export/hnorg/text/markdown/em...

- html: https://demo.filestash.app/api/export/hnorg/text/html/emacs....

- pdf: https://demo.filestash.app/api/export/hnorg/application/pdf/...

- more fancy plain text: https://demo.filestash.app/api/export/hnorg/text/plain/emacs...

there's more builtin and with plugin you can say extend the github markdown to cope with jekyll, hugo, ...etc

joaomsa7 lat temu

This looks really nice, do you have plans to implement text search of note contents? No matter how methodical I get with tags and hierarchies, nothing beats search for recall.

mickael-kerjean7 lat temu

It's the feature I'm working on as we speak :)

mickael-kerjean7 lat temu

The search has landed :)

joseph8th7 lat temu

Very cool.

aepiepaey7 lat temu

    pandoc -f org -t markdown <file>

lifthrasiir7 lat temu

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).

[1] https://docs.racket-lang.org/scribble/

[2] https://perldoc.perl.org/perlpod.html

astrobe_7 lat temu

Reading the comments here, it feels like people miss the whole point of markdown.

Markdown's raison d'être is, "if you follow these conventions when doing ASCII art formatting, the my program can transform this to HTML or whatever other format".

The conventions being mostly the ones used in the pre-HTML email era, like underlining headings with a bunch of ======.

Orgmode is completely different to that. Orgmode is an "outliner/GTD" at heart, but this aspect has been buried under a ton of features.

Then if you want "prawfishunal qvalitat" advanced formatting, typesetting and layout control what you really want is something like Latex. Yet another whole different thing.

hyperion20107 lat temu

The thing about org mode is that it has everything you need to do the full fancy latex typesetting without loosing the ability to export to other formats the way you do if you write raw latex. Of course there are times when you have no choice but to duplicate a block if you are doing something really fancy, but that is a fairly rare occurrence.

lifthrasiir7 lat temu

But Markdown was advertised as "a text-to-HTML conversion tool for web writers" [1]. The raison d'être as you stated is not an end goal but a possible benefit. Gruber may have thought that the extensibility of Markdown is done by raw HTML; now we know that's not enough.

[1] https://daringfireball.net/projects/markdown/

omaranto7 lat temu

Of course Org Mode is completely different, because it can do tons of other stuff. But among it's many features, it also has lightweight markup syntax about which you could claim "if you follow these conventions when doing ASCII art formatting, the my program can transform this to HTML or whatever other format". And the conventions in Org Mode are also email-like in the sense that they don't look out of place in something meant to be plain text. (Maybe finding some large email corpus could answer which syntax is more email-like between Org Mode and Markdown, and maybe Markdown wins on that front, but my point is both syntaxes are lightweight for the most commonly needed markup.)

klibertp7 lat temu

> Orgmode is completely different to that.

Org has just much larger scope than Md. The whole feature set of Markdown covers a tiny fraction of Org features.

NOTE: my use case is writing high-quality, good looking technical and user manual-like documentation.

Org-the-format is very close semantically to ReST - most of Org constructs have a direct equivalent in ReST, and vice versa - rather than to Markdown. And Org-the-system is very similar to Sphinx (the documentation/article/paper creation tool in Python) or Scribble. They are functionally equivalent - headless Emacs in Docker with Org/Babel and Sphinx - and it's unfortunately very hard to justify choosing the former over the latter. I know - I just tried this past half a year and failed, even though I could count on a lot of goodwill from my co-workers :(

(I'm ignoring the agenda, timelog, notes, spreadsheet, and all the kitchen sinks which also come with Org because they tend to be of private use, and I'm focusing on professional context)

The situation changes drastically, of course, if you do use Emacs. The Emacs' UI for Org, which is yet another thing from Org-the-format and Org-the-(headless)-executable-exporting-to-html/pdf, is incredibly powerful. Examples of features: storing, pasting and inserting and following links, footnotes, images. Structural modification of the document without hassle (no more missing text after reordering a list!). Ability to edit all code and examples in their corresponding modes (with syntax highlighting, autocomplete, etc.) Ability to run a single chosen code block with a key-press, inserting or updating (or not) the results into document. Support for editing tables - rearranging columns and rows. Latex, PlantUML, and dozens of other languages and tools integration... These are all very nice, very powerful features - and that's on top on whatever conveniences you have already configured in your Emacs, too.

Unfortunately, without the UI, Org is no more useful than Sphinx. On the other hand, no one's going to switch to another editor just to edit the docs, nor should they be forced to.

I like Org. I store my notes and some todo lists in it, I enjoy Babel (support for IPython/Jupyter notebook style development but polyglot), I maintain some parts of my blog in Org (long and unwieldy otherwise lists nested to a few levels). I cannot, however, see any reason to introduce Org as a tool for my team at work, unless they all see the light and come over to Emacs side :)

PS. a bit off-topic but I need to vent a bit: the API of Org is just awful! Functions for traversing the structure of the document are both in outline and org modes, and it's hard to know which is where and why. There are myriads of ways to get the current element, none of which is simple. A lot of the processing is still based on text search and substitution, instead of AST. It's not trivial to go from source to AST, either. I found at least 2 bugs in macro expansion code. I wanted to syntax-highlight the results of a code block (JSON was returned) and I had to hack around in header/keyword parsing for this. To be honest - some of my enthusiasm vanished after the experience :(

fouc7 lat temu

Those are not lightweight markup languages at all?

The main point of markdown is that it is supposed to look like a normal & readable text document in its own right. The transformation to html isn't absolutely necessary for readability.

neilv7 lat temu

I'm leaning towards agreement with you, especially for embedded API docs in code.

I've been using Scribble for embedded API docs for years,[1] and the formatted result looks great, and is very powerful and extensible (Scribble is actually a better LaTeX), but it's not nearly as readable in code as it could be.

I think I actually preferred my earlier three-comment-character-Texinfo format I had before, and I even wrote a converter to Scribble for it (so that it would look idiomatic), except Texinfo format just couldn't handle Racket types.

Now that I've put Racket on hold while I Rust a bit, in the interests of job-hunting, I'm happy to see Rust is using Markdown (coincidentally, also with the three-comment-character prefix).

[1] Here's one formatted example, everything coming from the code files and package metadata, no separate documentation files: https://www.neilvandyke.org/racket/roomba/

Crinus7 lat temu

I do not have anything online at the moment to show, but a small document processor i wrote some time ago used a @-based syntax which was essentially a tree of named nodes with attributes - essentially the same thing as XML, but with a simpler syntax that was something like:

    @Foo; is a standalone empty node named Foo
    @Foo[aa] has a "aa" attribute without a value
    @Foo[bb=cc] has a "bb" attribute with "cc" value
    @Foo[dd="hello, world",ee] has "dd" attribute with "hello, world" value and "ee" attribute without value
    @Foo{blah} has a "blah" text child
    @Foo{blah @Bar;} has "blah" and Bar children
    @Foo Bar shortcut for @Foo{Bar}
    @Foo{!{...}!} has ... as unprocessed content

So you can type something like @P{This is a @I nice @Link[target=foo]{example} of @TT{code} @Smile;.} which would be sort of equivalent to XML <P>This is a <I>nice</I> <Link target="foo">example</Link> of <TT>code</TT> <Smile/></P> (but with less repetition, especially for longer documents).

In my processor the tree is passed to a script that does the actual handling by going through the nodes, children, etc and creating the output text (HTML or whatever) - the processor itself has no knowledge of specific node names, any meaning lies in the scripts.

My biggest issue with the above though is that i do not like editing markup by hand, so at some point i want to replace all the above with a GUI tool that does the same job but in a more graphical way without the need for (visible to the user) markup syntax (so the above example would be edited as just text but with the "nice", "example" and "code" bits having representational styling).

smartmic7 lat temu

Looks a little bit like the Lout typesetting system on a first glance.

https://en.wikipedia.org/wiki/Lout_(software)

Crinus7 lat temu

Yes, it was mainly inspired by Lout (although i think there is a much older system that used a similar syntax - and GNU TexInfo also uses something similar, but i didn't knew about that at the time), however IIRC Lout doesn't use a generic syntax.

neilv7 lat temu

In a case of great minds think alike (you, Eli Barzilay, and Matthew Flatt), this (especially the square brackets and curly braces purposes) is remarkably similar to what Racket ended up using, for the @-reader syntax that's used by Scribble document processing: https://docs.racket-lang.org/scribble/reader.html#%28part._....

I made an Emacs mode for it: https://www.neilvandyke.org/scribble-emacs/

enriquto7 lat temu

having to close paragraphs is useless. It moves to the user of the markup a concern that is only of interest to the implementor. That should we exactly the other way round.

I prefer html5, where you can leave tags open as if there's no tomorrow.

Crinus7 lat temu

This is just the way i have the scripts setup since it makes more sense for me for paragraphs to be full nodes that contain their children content, but it is trivial to make empty P nodes act as paragraph separators.

enriquto7 lat temu

It is not a trivial matter when you are writing the markup manually. If you require to open and close paragraphs it becomes very cumbersome for no real gain (just a tiny amount of convenience for the programmer of the parser).

The ideal case is TeX, where paragraphs are separated by a blank line.

Crinus7 lat temu

With trivial i meant that it is trivial to have a script that makes @P; a separator (or start marker) if you prefer to work that way. I made the system script-driven with a generic syntax exactly because i didn't want to hardcode any specific way of working with the nodes.

As for TeX, i personally dislike markup languages where whitespace is treated in a special way since this is source code, which often needs some style of its own and sometimes that depends on context.

To me seeing where a paragraph - or any other "long" element - begins and ends can be helpful and if anything, i consider the lack of syntax for this in my markup as a negative (but i couldn't come up with a clean and unambiguous syntax for adding an optional "closing" bit). I compensate for that using comments (which look like @# Blah until the end of line), but it is a workaround.

And also FWIW i prefer to have the markup map to the underlying tree of nodes clearly than introduce "magic" that in some cases can make things harder even for writers.

Keep in mind though that this is for long(ish) documents, like a large tutorial, guide, manual, etc not short comments like this one here. For anything that is around the size of a common blog post or shorter, something more adhoc like Markdown is probably better.

enriquto7 lat temu

> As for TeX, i personally dislike markup languages where whitespace is treated in a special way since this is source code

just to nitpick: except for APL, white space is treated in a special way in all programming languages to separate tokens :)

Using it to separate text (words and paragraphs) makes perfect sense in this context.

Crinus7 lat temu

Perhaps i used a wrong description, but i meant having special cases/multiple uses and specifically about text markup languages. If every other element of the document tree, like sections, links, emphasis, references, images, figures, etc is marked using explicit syntax then using whitespace for paragraphs is inconsistent and can often be misleading since this will also need to be context sensitive as you do not want paragraphs to be inserted in every node that can have children.

But this is obviously a stylistic preference as to me that sounds too much trouble for no gain at all - which is basically your response above :-P.

But as i wrote in my original message, i'm not a big fan of these plaintext formats and i'd rather work using a "WYSIWYM" editor that uses these nodes behind the scenes instead of having the user write the markup by hand. But that is obviously much harder to implement (and if the tool handles the nodes for you the syntax doesn't matter at all anyway). Still, to me that is the ideal:-).

enriquto7 lat temu

> But as i wrote in my original message, i'm not a big fan of these plaintext formats and i'd rather work using a "WYSIWYM" editor

you will pry plain text editors from my cold, dead hands!

perlgeek7 lat temu

I'm a big fan of Perl myself, but when writing POD, I occasionally stumble about the C<...> for inline code.

The problem is that you have to take care that there is no > in the inline code, and if there is, you have to switch to C<< ... >>. With Markdown's `...`, this happened far less often to me.

lifthrasiir7 lat temu

You are right that it is suboptimal. (I do think that Scribble's choice of braces is not too bad in this regard.) On the other hand, I can't readily type backquotes in my mobile phone or recent macOS [1] so there is a trade-off :-)

[1] Annoyingly enough, macOS Sierra and later maps a backquote to a Won sign in Korean keyboard layouts.

elcritch7 lat temu

Never read scribble before but I kinda like it. It reminds me of the good parts of latex. As in @action vs \action. Though I don’t like the table syntax as much from a WYSIWYG level (E.g. it doesn’t look table-ly) but for complex tables it don’t matter much. Can you readily extend scribble with Racket and how’s the install/usage story?

Eugeleo7 lat temu

I know we're talking about docs right now, which is where Scribble really shines. And when it comes to blogging/prose, I'd recommend Pollen[1], which is a writing system based on scribble. It is fairly lightweight and extensible with Racket (which is by the way actually a pretty awesome language).

I'm writing my college notes in it and couldn't be happier. The dev is very responsive on mailing lists and would gladly help you out if you have some trouble initially. There is a pretty thorough getting started guide on the linked page. There's a few blogs written in Pollen and even a few books (Ever heard about Flatland? Or Practical Typography?).

[1] http://pollenpub.com

lifthrasiir7 lat temu

I think it is in the default Racket install. And yes, that's a problem; it is actually a Racket code behind the scene so it is fundamentally tied to Racket (that can be good or bad depending on your use case, and some strength points can be attributed to that).

Ultimatt7 lat temu

You might want to check out the Perl 6 extensions to POD https://docs.perl6.org/language/pod

fxfan7 lat temu

I haven't tried dozens but I really really wanted to like asciidoc and rst. But they both require me to type n number of '=' for title string of length n. I confess I fail to see the utility in this kind of design.

I'm still looking (Scribble seems anything but lightweight!). Perlpod probably looks perfect but I have to see more.

Is there a markup that can do numbered lists?

ben5097 lat temu

I feel the same way about RST; really wanted to like it, fought with it, gave up because Sphinx consistently seems to make simple things hard.

Regarding section titles, I think the theory is it makes it easier to stick new header levels into a document.

(For those who aren't familiar with RST: If it sees underlines like ====, ----, ^^^^ or ~~~~~, it decides what the header levels are based on the order in which it sees them.)

In practice, it means a typo makes it completely ignore your header, you have to learn a set of acceptable characters for headers, and there's no way to start a document with anything less than shouty H1.

Nice idea, though.

> Is there a markup that can do numbered lists?

Correctly and usably? NOPE.

earenndil7 lat temu

Why do you need markup for that?

1. first item

2. second

3. and so on

Markdown does parse that, but it seems superfluous to me tbh.

[deleted]7 lat temu

Ovid7 lat temu

As a huge fan of Perl and very comfortable writing POD, I despise POD. I would much prefer Markdown for documentation. It's easier to write and easier to read. Just try creating lists in each.

hollasch7 lat temu

If you haven't seen it yet, check out Markdeep: http://casual-effects.com/markdeep/.

Write in any text editor, and a tiny JS boilerplate turns it into nicely-rendered HTML.

skullborg7 lat temu

The flowcharts are gorgeous.

lloeki7 lat temu

Check out https://mermaidjs.github.io which is less visual in plain text but much easier to write.

desas7 lat temu

PlantUML is a good alternative too and has a good jetbrains plug-in

Jach7 lat temu

I came cross PlantUML recently, it's so much more than a classic diagram tool. I was particularly intrigued by their wireframe system: http://plantuml.com/salt

psnosignaluk7 lat temu

As we use Confluence for our collective brain, awareness of this was an unexpected bonus. Thank you.

baq7 lat temu

Yes they are but how to write them?

psnosignaluk7 lat temu

Arrived to read about a markup language, discovered something properly useful. Thank you.

jerguismi7 lat temu

Wow, genious idea.

sondr37 lat temu

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.

BeetleB7 lat temu

>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.

[1] https://ox-hugo.scripter.co/

kqr7 lat temu

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?

lucideer7 lat temu

That's beside the point. If the argument is: "Emacs has better standardisation than Markdown" (which is what the article purports), that argument is invalid if it depends on always using a single implementation. That's not how standards work.

i.e. If your answer to anyone's problem using Org is "what prevents you from using Emacs", then that ain't standardisation.

kqr7 lat temu

I think we're in violent agreement. The submitted article mischaracterises the level of standardisation around the Org format.

My comment was written with the intention of seeing if I could help with the specific problem the GP mentioned, since it seemed like the GP had overlooked a possible solution. I should have been more clear about that, sorry.

sondr37 lat temu

Mostly that Emacs only exports to HTML without any context of the content, in a blog you'd like to extract the metadata which org-mode doesn't, it just exports the whole buffer as HTML. I've been thinking about writing a blogging engine in pure Emacs Lisp, but I'm not sure if I'm that crazy yet :)

kqr7 lat temu

If at some point you want to feel what it's like to be that crazy, there's a chance you'll find that it's actually not that crazy at all!

When I created the current iteration of my website[1], I started out just adding some custom export formatting advice to the default ox functions. I couldn't resist add some additional functionality, though, and it takes refreshingly little work: There's one function that iterates through the Org source files and uses the built-in Org functions to query the files for tags, title, date, and so on. The result is memoised in a list, and then various other functions iterate through that list to generate index page, tag listing, and so on.

[1]: https://two-wrongs.com/

sondr37 lat temu

Now this is intriguing to me, do you have any pointers for a setup like this?

kaushalmodi7 lat temu

BeetleB already mentioned ox-hugo above. I happened to stumble across this thread (because Org mode!) and I am also the ox-hugo author.

I started working on ox-hugo exactly to have an Org export solution that exports the content + meta-data. If you look at the screenshots on the ox-hugo homepage (linked in BeetleB's comment), you'll see what I mean.

Ask me anything about it.

zelly7 lat temu

org has a static site generator built in. Takes a lot of configuration though: https://orgmode.org/worg/org-tutorials/org-publish-html-tuto...

enriquto7 lat temu

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.

mickael-kerjean7 lat temu

There's an ecosystem around org-mode that's developing. I made a client: https://demo.filestash.app/view/docs/tasks-projects.org?shar... the project is also open source https://github.com/mickael-kerjean/filestash

non-nil7 lat temu

There is indeed, and it's making me very hopeful for the future of org-mode. Beyond Filestash (great work!) there's the somewhat similar org-web [0], Beorg for iOS [1] and Orgzly for Android [2], all of which them leveraging the power of org-mode without requiring anyone hitting M-x or C-c even once.

What Markdown has going for it is a much wider acceptance as a simple, straightforward way to work with text. Especially on modern devices, users with little or no coding background are successfully being lured into (superior!) plaintext workflows by apps with a great UI, and appear to take to it. iA Writer [A] and Bear [B] are two prominent examples of such apps, and I can't see why they would be any worse (or less popular) apps had they instead opted for org-mode behind the scenes.

This is what org-mode needs to gain widespread adoption, and I'm hoping we're on our way there.

[0] https://github.com/DanielDe/org-web [1] https://beorgapp.com/ [2] http://www.orgzly.com/ [A] https://ia.net/writer [B] https://bear.app/

bthallplz7 lat temu

Way cool! The ecosystem is indeed developing:

I have been working on a Python way to import/export Orgmode files to/from an SQLite database that you can view and query in a native GUI (using Toga[0]). I was writing an Org-mode importing package for Python (to gain access to my Orgzly files and learn Python) until I found Orgnode[1]. I have the GUI table working, but I need to connect Orgnode to it and build an exporting system. You can follow this project at [2].

[0]: https://toga.readthedocs.io/en/latest/ [1]: http://members.optusnet.com.au/~charles57/GTD/orgnode.html [2]: https://gitlab.com/bthall/orcbench

anthonybullard7 lat temu

Thank you! This is looking really nice, I'll be taking a look at the source this afternoon.

xfer7 lat temu

This is excellent. Thank you for working on this.

sdwisely7 lat temu

I don't know that is bad.

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.

enriquto7 lat temu

> Without Emacs, org-mode is just weird markdown.

So, are you saying that the title of the article is bogus? Or that emacs is the only reasonable editor?

zeveb7 lat temu

> Or that emacs is the only reasonable editor?

Given the options, I think that a decent argument can be made that emacs is the best editor, and that it's unreasonable to use anything that the best — so yeah, one might argue that emacs is the only reasonable editor.

I don't know if I'd go quite that far, but I wouldn't instinctively disagree.

wowtip7 lat temu

My take is Emacs is the best integrated text processing environment available. But I am not sure it would beat VI/VIM as an text editor.

I don't think most Emacs users could match a good VIM user in text editing speed, but then Emacs can do many other tasks that are hard to replicate in VIM, while being a more than good enough editor.

It is not so much which editor is better, rather what are the user's expectations.

To me this is obvious and has been probably been said a 1000 times before, but sometimes when reading threads about text editors, you would not think so.

sdwisely7 lat temu

Neither,

Emacs takes an everything and the kitchen sink approach and org-mode embraces that.

afiori7 lat temu

> just doesn't make sense outside Emacs

That is the entire point. If I can only use it inside emacs then I will only use it inside emacs.

nukeop7 lat temu

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?

enriquto7 lat temu

> The day jazz will reach the masses is when the reviews about it do not even mention the word "black".

Indeed, and most of them don't nowadays!

> It's created by emacs users, for emacs users, it should absolutely mention that word everywhere and stress its origins

Of course, when you are explaining the history of org-mode you can mention it. Or when you are explaining how to org-mode with emacs. But to promote org-mode as a generic markup language (which I think is a very good idea), any mention of emacs, even indirect, should be best omitted.

> 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?

I love emacs and I like to use it, no idea who are you taking about. Or was it sarcasm?

kemitchell7 lat temu

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.

agentultra7 lat temu

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.

enitihas7 lat temu

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.

jeromenerf7 lat temu

Pretty much the same. Emacs with evil vim like bindings to edit .org files. I do a fair share of code within .org files though and it’s fine.

People complain a bit too much about productivity and context switching.

black-tea7 lat temu

Org-mode and magit were the reasons that I had to use emacs. Ended up falling in love with emacs itself, though.

db48x7 lat temu

Magit does make pretty good bait.

wzdd7 lat temu

Might be time to plug my very orgmode-esque Vim plugin: https://github.com/nfd/disorganiser

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.

lloeki7 lat temu

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.

[0]: https://github.com/DavidAnson/markdownlint

[1]: https://github.com/DavidAnson/vscode-markdownlint

zwp7 lat temu

> ad hoc syntaxes like JIRA's

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-kerjean7 lat temu

> bijective to org syntax

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.

tomcam7 lat temu

Some versions support HTML-style comments

lloeki7 lat temu

They may very well exist but I’ve yet to encounter one that does not.

bluenose697 lat temu

+1 for "branch predicts"

xamde7 lat temu

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.

[deleted]7 lat temu

tmm847 lat temu

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.

geogra47 lat temu

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

sandGorgon7 lat temu

agreed and much more compatible with pandoc and https://asciidoctor.org/

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

kqr7 lat temu

Are you saying Org does not have code blocks?

zelly7 lat temu

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)

...makes a flashcard like:

   -------------- --------------
  | Python3      | - 'r' ...    |
  | :: IO        |   .          |
  | :: modes     |   .          |
  |              |   .          |
   -------------- --------------

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.

BeetleB7 lat temu

Just as an FYI, Org mode has a flashcard software (org-drill).

(Broken on Org 9.x - not sure if they fixed it - you may need to use 8.x).

zelly7 lat temu

I tried that but it didn't have all the features I wanted. Specifically, I wanted to be able to make a list of subheadings as a flashcard (the front side being the headlines above). There's a lot of information you can encode in just the hierarchy for free.

tpaschalis7 lat temu

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.

crispyambulance7 lat temu

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"?

chipotle_coyote7 lat temu

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.

fourier_mode7 lat temu

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.

joseph8th7 lat temu

Agreed. Sadly ox export for markdown doesn't render markdown tables. Of course, as the OP argues, that's a little like exporting PDF to EPS.

jopsen7 lat temu

Actually, looks very reasonable :)

But adopting trumps perfection, hence, GFM is probably the most reasonable choice for new applications today.

013a7 lat temu

> Org-Mode Is Standardized

Let's be totally clear about this: If Org-Mode were actually popular, it too would have twelve variants. It is not popular.

LoSboccacc7 lat temu

> consistent, intuitive, standard

about that, just found some random online editor and entered this:

https://i.imgur.com/Mcyi3kS.png

not what I'd call intuitive. maybe is that particular editor implementation? but then I'd have an issue with the other half of the post, where he talks down markdown dialects.

zaarn7 lat temu

The article title is missing a footnote:

"Only if you use EMacs, as Org-Mode is impossible to implement outside of EMacs".

Source: tried once as someone who never used org-mode or emacs. Did not go well.

mickael-kerjean7 lat temu

I built a complete web app for org-mode: https://demo.filestash.app/s/hnorg ho and it's open source https://github.com/mickael-kerjean/filestash

julienchastang7 lat temu

Hey, this looks pretty nice! Could you elaborate a bit here on what this is?

narrator7 lat temu

I like Wikitext[1] which is Mediawiki's markup. Mediawiki is the software that runs Wikipedia. I have a personal Mediawiki that I use for taking notes and it works a lot better than org-mode in that it is easy to make tables, nicely formatted outlines , hypertext, etc. Chrome has a plugin that lets you edit textboxes in emacs too so you can use a real text editor instead of just chrome textboxes.

[1] https://meta.wikimedia.org/wiki/Help:Wikitext_examples

celadevra_7 lat temu

Org-mode syntax is no better than that of AsciiDoc, or arguably Markdown.

But I can assign keywords and unique id to sections, include sections from another file, generate indexes and sitemaps in fully customizable manners, incorporate other programming environments. What markup languages can do that?

Org-Mode syntax is an interface to a powerful writing/authoring environment. To dismiss it as a `markup language' is not a good way to advocate its adoption. Something similar can be said to ways people appreciate the power of Emacs.

ggm7 lat temu

What we need is more time machines so we can go back in the past and make even more future choices. Because just splitting amongst the choices we have is so .. limiting.

I do kind of wish we only had one markdown flavour. Maybe why we only have one org mode is because of its lack of ubiquitousness? If it had an electron windows version would it be the same?

The commensurate note is, everything here (Bar one) says it's a stalking horse for Emacs

011000117 lat temu

Maybe I'm just old but I miss the old MoinMoin syntax. A lot of markups are so complicated (mediawiki) I'd rather just write HTML.

For my personal notes I now just use vim and a custom syntax file to give color to special names and headings. I've used markdown before but it seemed like different tools treated the language slightly different.

lifthrasiir7 lat temu

I do the same for my personal notes. Something like (the actual contents differ because I take notes in my native tongue):

    if exists("b:current_syntax")
      finish
    endif
    
    syn match diaryHashtag "\w\@<!#[A-Za-z]\+"
    syn match diaryInlineCode "`[^`]\+`"
    syn match diaryLineMarker "^[ \t]*\%([0-9]\+\.\|[*-]\)\S\@!"
    syn match diaryInlineMarker "=>\|\S\@<!(\?\%(i\{1,3}\|iv\|vi\{0,3}\|ix\|x\))\S\@!"
    syn match diaryInlineDate "\<\%(today\|yesterday\|tomorrow\|\%(\%(next\|last\)\s\)\=\%(mon\|tue\|wed\|thu\|fri\|sat\|sun\)\|20\d\d-\d\d\%(-\d\d\)\=\)"
    syn match diaryInlineTime "\<\%(\d\d\=:\d\d\|morning\|afternoon\|night\)"
    
    hi default link diaryHashtag String
    hi default link diaryInlineCode Delimiter
    hi default link diaryLineMarker Statement
    hi default link diaryInlineMarker Statement
    hi default link diaryInlineDate Comment
    hi default link diaryInlineTime Comment
    
    let b:current_syntax = 'diary'

But this system is entirely unusable for longer and potentially public writings.

pcnix7 lat temu

I used something similar, along with a few additions to add timestamp as a column on the left etc.

I've since switched over to org-mode though, I find that the agenda integration and a couple of org-journal plugins make for easy task management. I'd really like an alternative that lets me handle this on mobile, so far I've tried termux and the github edit file interface, and neither are as satisfactory.

IshKebab7 lat temu

Unconvincing. Markdown surely has way better tool support.

The lack of standardisation is probably the best argument, but I suspect that is mostly not a problem for Org mode simply because barely anyone uses it. If it were as popular as Markdown you'd find plenty of non-standard extensions and slightly different implementations.

sevensor7 lat temu

Having written my dissertation in markdown, and having not tried org-mode, I'm intrigued. The thing about multiple markdown implementations is a bit of a red herring. The subtly different problem with markdown is not multiple implementations, but a syntax with too many alternative ways of doing the same thing. Section headers, tables, raw HTML, raw LaTeX -- it's kind of a mess. Multiple flavors make this worse by supporting subtly different variants of the alternative syntaxes, but the core of the problem is that the original specification was "whatever this perl script does," and that leads to weird corner cases.

The appealing case for org-mode is consistent syntax. At least that's what it looks like from a distance. Like I said, I haven't tried it.

maga_20207 lat temu

what do you think about Org2Blog [1] (it supports math notation as well as integrated publishing from orgmode to wordpress) ?

I would like to minimize my learning curves, so wanted to get a performant blogging service installed on a 2.50$ Vultr instance, and keep using Emacs for blogging with something that includes math typesetting.

org2blog seems to be fit closest to what I am looking for (but I would prefer something other than wordpress if I have a choice).

[1] https://github.com/org2blog/org2blog

byproxy7 lat temu

Makes me think of a comment I posted not too long ago (and it's responses) : https://news.ycombinator.com/item?id=19474623

Reasonable for text...for most text that's skeuomorphic with regards to the printed word (in most senses). But... what is there for that which is beyond? A response to the linked comment mentions TEI (Text Encoding Initiative). Anything else? Is it too vast a problem in that we should make due with solutions that cover 90% of use-cases? Ah, but does that limit potential future development as people mold themselves to the constraints placed on them by the tools and what those tools allow?

Just thinking out loud, per usual.

ogre_codes7 lat temu

It fills most of the same niches as a tool which is currently extremely widely used (Markdown) without having any major benefits over it. Probably the single biggest improvement I see is the link syntax which I find bothersome in Markdown for the reasons the author suggests (parens first or brackets first). Aside from that, tooling for Markdown is massively better with dozens of tools supporting Markdown parsing and authoring. Yes there are a lot of sub-versions of Markdown, but if you know the basic markdown features you can use any of them.

submeta7 lat temu

> ... without having any major benefits over it.

How about tables?

ogre_codes7 lat temu

Fair point.

Though I would suggest that one of the strengths of Markdown is the fact that the basics are simple and easy to understand and it leaves more advanced concepts to specific implementations. So there are implementations for everything from code comments (https://www.hackingwithswift.com/example-code/language/how-t...) to Script Writing (https://fountain.io) which have features specific to their respective domains. Markdown itself doesn't have a huge featureset but the sub-markup languages which inherit from it do.

Edit: What I find more confusing about Markdown is actually incomplete implementations like what's used by HN.

rini177 lat temu

Such free-style formats are easy and addictive, but you eventually hit some well-hidden sharp corners. For example I missed some deadlines without any warning from emacs nor any indication with syntax higlighting when I had:

    * TODO stuff
    text <- no text should be here!!
    DEADLINE: <date>

Not to mention I am vim user and ANY vim compatibility layer for emacs eventually goes infuriatingly against my muscle memory.

pwinnski7 lat temu

I sometimes think that Org-mode suffers in the same way that SGML lost to HTML, SOAP lost to XML-RPC, Atom lost to RSS, XML lost to JSON, and so on. What some people see as the over-simplicity of Markdown is exactly what leads to it being implemented "everywhere." The simpler format often ends up being more widely used precisely because of its simplicity, not despite it.

pmoriarty7 lat temu

The analogy breaks down because the complexity in org-mode is completely optional.

You don't have to use or even know of all of org-mode's features in order to use it. You could use a tiny subset of features and still have a valid org-mode file which is as simple as any other markdown format.

In fact, that's exactly how most people use it. But if they want more power, it's there.

What's more likely to be the reason for org-mode's lack of adoption is that most people don't use emacs.

Aardwolf7 lat temu

Another one that doesn't respect line breaks

What is the reason why all those lightweight markup languages don't preserve plain text line breaks by default without special formatting?

It would be much easier to use if they did, if I hit enter in plain text it's for a reason

I like BBCode, and that one preserves your line breaks too

blablabla1237 lat temu

Org mode is great, at work I use it since half a year to keep myself organized. For instance when I'm debugging something, I can keep notes and clues or the sometimes not avoidable request that just won't fit into the issue tracker.

otterpro7 lat temu

Previously in https://news.ycombinator.com/item?id=15321850

CivBase7 lat temu

This looks very similar to markdown. I wonder how org-mode distinguishes itself.

> Org-Mode is Standardized

> the very widely used markup language named Markdown has many flavors to choose from

I believe the XKCD about standards applies here.[0]

The problem with Markdown is only real if you treat Markdown as a single language instead of a family of languages. You don't need to support multiple Markdown compilers. Just pick a particular flavor of Markdown to support for your project. I usually go with GitHub's.

Besides, having a standard doesn't stop others from adding unofficial features on top of that standard. If this happens to take off, maybe I'll be using GitHub Flavored Org-Mode in the future.

[0] https://xkcd.com/927/

burtonator7 lat temu

I'm surprised how many people use org-mode.

At least on Hacker News... a Lot of the Polar users mention org-mode as one of the other tools they're using.

asciimov7 lat temu

I've always wanted to learn org-mode and emacs.

Can anybody recommend a good tutorial?

Also, should I learn pure emacs or go the spacemacs route? My background is in vim.

zaiste7 lat temu

Another, long-time Vim user here. I recommend Emacs Doom [1]. It was built especially with Vim users in mind.

[1]: https://github.com/hlissner/doom-emacs

dillon7 lat temu

Vim user here. I use Vim for pretty much everything, but I do have Spacemacs installed purely for two modes:

1. Org-Mode

2. Regex Mode

org-mode is just too good not to use. I use it for interview notes, writing documentation for other teams and non-technical staff, my blog, and probably other stuff I can't think of right now.

The part where I heavily disagree with the author of this article is when he says you don't have to use emacs for org-mode. My, personal, belief is you're missing out of some of the power if you opt for Vim + Pandoc. The exporters in emacs support a lot more features (that I do use) than Pandoc does. If you can get away with just Pandoc then great, but I opted for Spacemacs (coming from Vim).

zeveb7 lat temu

Coming from vim, I'd suggest spacemacs, following along with whatever docs they have.

Coming from anywhere else, I'd just start with the emacs tutorial (C-h t) and then move on from there.

I personally think that there's a lot to like about the vi text-manipulation commands, but that spacemacs does a bit too much out of the box. I just use Prelude:-)

exabrial7 lat temu

So markdown. But standardized. Again.

BeetleB7 lat temu

Org mode predates markdown.

ninju7 lat temu

> Org-Mode Is Standardized

(until it isn't)

I'm assuming all of the variations of Markdown that were created were created without knowledge of the original Markdown creator.

Is the OP going to monitor all open source projects and block people from creating an improvement of Org-Mode

ternaryoperator7 lat temu

>(until it isn't)

There is only one version of Org-Mode, with its own reference implementation, and it's been that way for years.

>I'm assuming all of the variations of Markdown that were created were created without knowledge of the original Markdown creator.

Not so. Daring Fireball was repeatedly asked to participate in advancing, changing, standardizing MD, but chose not to. He was well aware of the variants emerging.

>Is the OP going to monitor all open source projects and block people from creating an improvement of Org-Mode

That's not how reference implementations work. The only thing that matters are variants that get enough traction.

nitwhiz7 lat temu

This is just markdown..

skookumchuck7 lat temu

    : Simple pre-formatted text such as for source code.
    : This also respects the line breaks. *bold* is not bold here.

The trouble with that is you cannot easily copy/paste code to/from it, because you'll need to manually add/subtract the : prefix. Delineating the section with:

    ```
    Simple pre-formatted text such as for source code.
    This also respects the line breaks. *bold* is not bold here.
    ```

is much more practical.

confounded7 lat temu

They’re not mentioned in the article, but org-mode does have syntax for source blocks (a little uglier than Commonmark/Github-flavor markdown’s blocks in my opinion, but it does the same thing and works well).

TeMPOraL7 lat temu

It may seem uglier if you use it first time:

  #+BEGIN_SRC lisp
    (format t "Hello world!~&")
  #+END_SRC

but it has two things going for it.

One, it's consistent with other blocks, like BEGIN_QUOTE, BEGIN_EXAMPLE, BEGIN_VERSE, etc. (n.b. all four have a default shorthand that gets tab-expanded; <s. <q, <e and <v, respectively) , and with arbitrary user-defined blocks like BEGIN_whatever.

Two, while #+BEGIN_SRC may seem only an unnecessarily verbose way of writing ```, things change when the block starts to look like this:

  #+NAME: advanced-block
  #+BEGIN_SRC lisp :package my-package :var foo=123 :var bar=asdf :noweb yes :exports both :eval never-export
    <<preamble>>
    (format t "Hello ~A!~&" <<some-other-block(param=3.14)>> )
  #+END_SRC

AKA. a named source block (so I can reference it elsewhere) of Lisp executing in selected Lisp package, with org mode variables injected into it, using noweb syntax (literate programming) for injecting other code blocks[0], which when exporting the document to a different format (say, PDF) will export both code and results of its evaluation, but will not automatically evaluate the code.

This feature makes Org Mode essentially a kind of better Jupyter, with automatic support for any and all possible language that you can plug into Emacs, simultaneously.

--

[0] -- here, it'll paste the literal contents of #+BEGIN_SRC block with #+NAME: preamble at the beginning, and then paste the results of executing a block with #+NAME: some-other-block, with value 3.14 for its :var param, at the end

kqr7 lat temu

I have a slight preference for

      #+NAME: advanced-block
      #+HEADER: :noweb yes :exports both :eval never-export
      #+HEADER: :package my-package :var foo=123 :var bar=asdf 
      #+BEGIN_SRC lisp
        <<preamble>>
        (format t "Hello ~A!~&" <<some-other-block(param=3.14)>> )
      #+END_SRC

(Just wanted to point out that the header format has even more flexibility than what you've shown!)

_lbaq7 lat temu

And you can execute that code too with Babel ———> https://orgmode.org/worg/org-contrib/babel/

etu7 lat temu

  #+BEGIN_SRC sh
  #!/bin/sh

  echo "foobar"
  #+END_SRC

That also works in org-mode, and then you get syntax highlighting for the language etc. It can even open that block to edit in a separate buffer with the right major mode loaded for that language.

xemdetia7 lat temu

The command is org-edit-special bound to C-c ' (by default I think). I use this to dump example blocks which I often use to catch terminal output as well as source code editing. Having structured outputs from test/investigation/exploring that you can rearrange and export to use as documentation for the next time/training costs so little time that I get upset when I can't do it.

adbge7 lat temu

M-x comment-region

roenxi7 lat temu

This deserves a little expansion - Org Mode makes the reasonable-in-context assumption that the user is familiar with Emacs.

At that point, adding or removing a ':' is not a repetitive task. Then the ':' notation gains an advantage because selected lines can be copied and automatically keep their formatted status.

jacobolus7 lat temu

In any reasonable editor, “manually add/subtract the prefix” is an easy keyboard shortcut.

zapzupnz7 lat temu

Except one is not always able to use an editor, and assuming people are always able to do something is a great downfall of many products or standards made by people with specific uses cases in mind who think their experiences are universally applicable.

jacobolus7 lat temu

I thought the writeup was about emacs org-mode. Who is planning to use that in a context where the text editor can’t handle basic features from 40+ years ago?

zapzupnz7 lat temu

The write up very specifically mentions it is about org-mode as a general purpose markup language.

The very first line after the disclaimer even reads "Please do note that this is not about Emacs".

black-tea7 lat temu

(1)

anbop7 lat temu

I refuse to use a plain text editor for my personal notes. Bold, italic, underline, text highlighting... these are all things that help me organize text and draw my attention to certain areas. Asterisks simply don't do the same job, visually.

mikekchar7 lat temu

Luckily for you Emacs lets you set the faces (emacs's name for syntax highlighting) however you want it. You get the best of both worlds: convenient keyboard interface and marked up text in the editor.

kqr7 lat temu

Emacs Org supports three different settings in terms of this:

- Show styling sigils and keep text plain;

- Show styling sigils AND style the text;

- Hide styling sigils and style the text.

In my experience, the middle option really hits the sweet spot.

mruts7 lat temu

..which is why you wouldn’t use org-mode? Org-mode does all of those things and more: inline images, tables, latex, etc.

mruts7 lat temu

org-mode with latex yasnippet expansions is the best note taking method I’ve ever used. Inline images, tables, ans latex. So seemless.