Comment by lucideer | Hacker News Reader

Comment by lucideer | Hacker News Reader

Parent Full thread

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

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.

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

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

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

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

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.

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.

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?

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.

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.

> I think you have made several incorrect statements.

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

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

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

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.

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.

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.

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.

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

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.

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

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.

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

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

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

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

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.

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

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

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.

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

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?

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.

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

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.

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

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

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

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.

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

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

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

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?

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.

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

Reply on news.ycombinator.com