Hacker News Reader

Comment by tconfrey | Hacker News Reader

+1 for plain-text for all the points you mention, particularly "data-first with tools on top". But why reinvent the wheel when the org-mode format is well established and does everything you want, and more?

There are an increasing number of tools using org-mode as a plain-text data store, so you are more likely to be able to participate in a tool ecosystem. In addition to my own https://braintool.org see the list below. BrainTool (mainly a bookmark manager) has an elemental to-do system, I'd love to have my users be able to use your tool for todos.

NB see also Karl Voit's push for org markup awareness outside of Emacs via Orgdown: https://gitlab.com/publicvoit/orgdown.

------ ORG-MODE TOOLS OUTSIDE EMACS

https://plainorg.com

https://flathabits.com

https://beorg.app

https://braintool.org

https://easyorgmode.com

https://logseq.com

https://organice.200ok.ch

https://orgro.org

http://orgzly.com

View on HN

Isn't org-mode tied to emacs? Also, does it have a specification? I searched for a specification and found this (https://orgmode.org/worg/dev/org-syntax.html) and couldn't understand whether it is a proper spec. Without a well-defined spec, it becomes very hard to create tooling around it. For example, Markdown was using Perl scripts initially and didn't have a spec for some time.

org-mode does not have a spec. Its Emacs implementation is the canonical implementation. But org-mode is still just plaintext, and you can read org-mode files using any plaintext editor.

Yeah but its difficult to look at and read as purely plain text, unlike markdown. And since the power-features of org arent available in your editor(s) (unless you use Emacs) it isn't tenable. I'm convinced Emacs users are blind to this given the seemless rendering done by Emacs. There's room for a new spec.

Obviously I'm biased since I built BrainTool because of my emacs/org use, but I also use markdowns and maintain the braintool.org blog on github in their markdown. I don't find it more readable. Maybe it's a familiarity thing, anything specific you dislike?

Anyway here's the definitive argument for org as markup of choice: https://karl-voit.at/2017/09/23/orgmode-as-markup-only/

It would for sure be nice to have a definitive spec to point to, independent of the emacs ecosystem.

BTW see below the first few lines of my dev-log.org file for yesterday. I think its pretty readable!

* <2022-03-30 Wed>

** DONE Today [83%]

   - [X] Call w alex

   - [X] Exercise

   - [X] instructions to Alex

   - [X] letter to Deignan

   - [X] taxes

   - [ ] styling for notes col

** DONE bug narrow edit card shows item under bullet which is confusing. :dev:099:

** DONE get rid of link in welcome topic, too confusing :dev:099:

** Instructions for running BrainTool locally:

   1) Make sure you have git installed. (https://git-scm.com/download/mac)

   2) Make a folder where you want to put the code

That's still too many formatting bits for me.

My weekly todos look something like this:

It uses a simialr format:

YYYYMMDD

- Task to be done

  - Subtask

  * Note about task

/ Task started/half done

x Task completed

ie:

20220328

- finish baselining instances for ami creation

  x server 1

  / server 2

  - server 3

   * Make sure RH image is being used vs AWS provided AMI

/ verify routes exist for all subnets

x snapshot instance X before users are added

-- Dave

You can have YYMMDD too.. its just how he's input it.

IMHO: Workflow, Text input fields and File formats are like APIs; if there is a way to abuse, hidden or public, then someone will use that in their process (https://xkcd.com/1172/). So adhering to Org mode in your own parser will mean a lot of work anyway. There will always be some subtle point that make your format incompatible with a tool you want to use.

One of the clear problems I have with this format is that you have to write a dash in front of every todo. This may seem like a minor gripe, but when writing todos is by far the most common action, it really does increase the friction a lot.

Sibling comment already addressed the readability of the source, but I'd like to ask what rendering you mean exactly?

The "rendering" I see in an open org-mode file right now is a) coloring and b) collapsing. So apart from hiding and coloring things I think what emacs shows is exactly the source, at least in my configuration. Did I miss something?

When I last played with it (Emacs + Org) I had options enabled which hid much of the markup entirely (e.g. the **) and applied various styles to express the intended structure, and it was lovely, much more than just coloring. Nothing I'm saying is without love for Emacs and Org, more just sulky acceptance that tools can add additional mental overhead, even if they're cool, and this seems to be the opinion/philosophy of modern tools etc, VSCode/IDEs/Web-based IDEs etc.

So.... when I tried to use Org in VSCode, Vim, Notepad etc, it just sucked. Not even a comparison. In that case, Markdown was better. Maybe I'll look at it again. But like the OP (in the sense of making up my own thing) I have dabbled in creating my own clone of Org-mode based on a Markdown spec.

Hmm ok, I never have these options on. For no particular reasons other than that they don't seem to be the default (or something's wrong with my config), and I never missed any additional application of style.

So it's possible that I just got very much used to how org-mode "source" looks.

Yes, for task management and for any other applications, Emacs offers programmable views of Org files.

A popular view of Org files that comes already builtin in Emacs is the agenda view.

The agenda view lets you query all todos, incoming deadlines, scheduled appointments, etc. harvested from a list of Org files.

For example, I can quickly see all todos, incoming deadlines, scheduled appointments, holidays etc. for an arbitrary period of time, say week 40 of 2022.

Yeah, but this was about comparing markdown and org-mode (for readability and probably visual appeal), and rendering the "raw" buffer.

Is it really that much harder to read than Markdown?

- Headings: Markdown uses #, Org uses asterisks.

- Italic: Markdown uses asterisks or underscores, Org uses /

- Bold: Markdown uses double asteriskes, Org uses asterisks

- Inline Code: Markdown uses backticks, Org uses =

- List items: both use dashes

- Links: Markdown uses [description](url), Org uses [[url][description]]

- Code blocks: Markdown indents each line by four spaces, or some modern dialects use tripe backquotes, Org uses #+begin_src, #+end_src tags

There's at least a parser using that as a spec at https://github.com/200ok-ch/org-parser

also this one: https://github.com/orgapp/orgajs

It parses, but it's not interactive at all. For example, it doesn't run code blocks, iirc

Last time I checked, there was an extension for org-mode in Visual Studio Code, but it felt a bit more like a glorified WSIWYG markdown editor with a few extra features - just a tiny, tiny fraction of org-mode's potential. But that tiny fraction alone covers a wide variety of use cases.

You can get quite far with it. I’ve used https://orgmode.org/worg/dev/org-syntax.html when implementing lots of https://plainorg.com and https://flathabits.com.

There are implementations for other editors, for example NeoVim[1].

[1] https://github.com/nvim-orgmode/orgmode

> org-mode format is well established

Is there a formal specification or documentation on the format? When I've previously read about integrating org-mode support in other threads, the lack of specification outside of "whatever org-mode does" was the biggest blocker.

I’ve never used org-mode but have heard enough about it to be intrigued. If there’s no spec and it’s “whatever the emacs implementation is” then I think there is plenty of room for a plaintext alternative.

https://orgmode.org/worg/dev/org-syntax.html

Is there anything that isn't Orgzly for Android? I found the app very finicky from my basic usage and very difficult to use.

Funny that all the phone versions have a hard coded UI. Isn't the point that org mode is just plain text so it's more free from? I currently use google keep. I'm not recommending it but to some extent I can use at as just a collection of synced text files.

The only phone version I've used is beorg, but beorg lets you directly edit the plaintext if you want to. I usually don't because the hard coded UI is pretty convenient.

A mobile-friendly interface that enables jotting things down quickly while on the go… (coincidentally, fully typing “- [ ] remember the milk” is clunky on mobile, switching keyboard, etc).

Also powered by plain text, so you can drop down to the details whenever you want to (including your mobile) with all the portability associated with it.

disclosure: I wrote https://plainorg.com and https://flathabits.com because I wanted a frictionless mobile experience without giving up on org markup (plain text).

Thank you. Every time I come across some "plaintext" enthusiast who refuses to acknowledge that mobile devices are not conducive to free-form text editing of structured text files, I want to punch them in the face.

Mobile devices require context-aware, guided data entry/editing interfaces.

I beg to differ. I find google keep / apple notes to be much more useful in mobile precisely because they are free from. I can enter lists , notes, phone numbers , links, all in the same document and usually get far more info on the screen.

Conversely every fixed ux tool I've used for this fails miserably because too little data since it's wasted by ux and small non freeform fields in widget that have limited space.

Further, I can easily cut/copy/paste large sections across documents where as in most fixed ux apps I'd at best only be able to move one item at a time and at worst have to manually copy each field from each widget to each field in another widget

These look great! Pity that it is iOS only since I use a Pixel.

How did you create the videos at the top of the page? It's very well done

> How did you create the videos at the top of the page? It's very well done

Thanks. Unexpectedly, Keynote.

I followed a tutorial I bookmarked from HN ;)

https://news.ycombinator.com/item?id=18805222

Thanks! I had seen that post and promptly forgot about it :facepalm:

(Author of Orgro here)

Orgro displays the file as "rich" text, so it is not a "hard-coded" UI; it's much closer to viewing the file as you would in Emacs.

That said, it is definitely lacking compared to Emacs: it's a viewer only and mostly doesn't interpret the file contents; you can't execute code blocks, etc.

Reply on news.ycombinator.com