[HN Gopher] Org Mode Is One of the Most Reasonable Markup Langua...
___________________________________________________________________
Org Mode Is One of the Most Reasonable Markup Languages to Use for
Text (2017)
Author : Tomte
Score : 100 points
Date : 2021-11-18 08:46 UTC (14 hours ago)
(HTM) web link (karl-voit.at)
(TXT) w3m dump (karl-voit.at)
| taeric wrote:
| It is telling that most of the complaints on org-mode seem to be
| from folks that haven't used it. And never intend to use it.
| Mainly because of emacs.
|
| Which is a shame. I think Jupyter mainly steals a ton of market
| from Mathematica and Matlab, without most of it's users ever
| having seen those offerings. Org has the advantage that it is not
| tied to any specific extension language. It is all a cdata style
| delimited text block with contacts on environment setup and tear
| down. With the output being fair have for editing.
| searene wrote:
| I think the biggest advantage of Org Mode over Markdown is that
| Org Mode can attach properties to headers. This seems trivial,
| but it's not. Because of that, you can:
|
| 1. Give a header an id and jump to it from anywhere.
|
| 2. Attach scheduling information to the header so that you can
| easily track TODOs and DONEs. I usually further break down a TODO
| into several sub-TODOs and write something under each one to
| organize my thoughts, including code blocks, tables, quotes,
| footnotes, which is impossible in Markdown.
|
| 3. You can attach anything else to it, too. I also attach an Anki
| note ID to it and use Org Mode as an alternative Anki editing
| environment. Because of the attached note ID, I can easily
| distinguish whether I want to create a new Anki card (without an
| ID) or update an existing one (with an ID). That is also hard to
| implement in Markdown (Strictly speaking, I don't think it's even
| possible to implement it in Markdown).
|
| My only complaint is that Emacs is the only text editor that
| fully supports Org Mode. Other editors (e.g. vim, VSCode) support
| it too, with only to an extent.
|
| Sometimes I also wonder why Org Mode is not as popular as
| Markdown, the former is far more powerful.
| chipotle_coyote wrote:
| > Sometimes I also wonder why Org Mode is not as popular as
| Markdown, the former is far more powerful.
|
| The reliance on Emacs has been mentioned by a fair number of
| commenters already, but there's also another issue here, I
| think -- there are a lot of Markdown variants, and while that's
| usually described as a flaw rather than a feature, the silver
| lining is that there probably _is_ a Markdown processor that
| can handle [thing that you want], from citations to cross-
| references to math formulas. "But then I'm tied to that
| variant of Markdown" is a valid objection, but it's not one
| that's really answered by Org Mode.
|
| In practice, some Markdown syntax that started as "non-standard
| extensions" -- most notably tables and footnotes -- has been
| widely adopted by most processors. Several processors I know of
| _do_ have ways to attach labels or other metadata to sections,
| such as MultiMarkdown 's cross-references.
|
| > I usually further break down a TODO into several sub-TODOs
| and write something under each one to organize my thoughts,
| including code blocks, tables, quotes, footnotes, which is
| impossible in Markdown.
|
| This one I'm not actually sure I'm following. You can certainly
| insert code blocks, tables, quotes, and footnotes under
| subheadings and even under indented lists.
|
| Org Mode is absolutely better as a task manager and day planner
| -- but that's not a function of Org Mode's markup syntax,
| except to the degree the syntax has specific features for
| supporting tasks and agendas. It's a function of Org Mode
| being, well, a _mode,_ with a lot of specific functionality in
| Emacs. For _general purpose document markup,_ it 's probably as
| good as (e.g.) MultiMarkdown, but not better; if you're
| comfortable with one, there'd be little obvious reason to
| switch to the other.
| bloopernova wrote:
| > Sometimes I also wonder why Org Mode is not as popular as
| Markdown, the former is far more powerful.
|
| Markdown is plain text at one end of the complexity
| continuum. Microsoft Word is towards the other end. Org-mode
| is somewhere in-between.
| nanna wrote:
| > Sometimes I also wonder why Org Mode is not as popular as
| Markdown, the former is far more powerful.
|
| Because it's so integrated with Emacs, and all other editors
| are second class citizens (/hosts)?
| mumblemumble wrote:
| Also, it's kind of right there in the name. "Org _Mode_ ".
| It's not just a markup format, it's an emacs mode.
|
| My org files quickly accumulate custom elisp snippets for
| automating small one-off things like rendering embedded dot
| with Graphviz and displaying them inline. I don't think I'm
| alone in that. Unfortunately, that creates a situation where,
| whenever I try to work with org files in other editors,
| there's a certain "it's like opening Photoshop files in MS
| Paint" aspect to the experience. Too many things that I've
| come to take for granted about how I'd interact with and edit
| these files no longer works.
|
| Markdown, on the other hand, is just a markup format. It has
| lots of dialects, but it isn't really owned by anyone. That
| creates a very different power structure: Markdown editors
| are free to just try to make a good Markdown editing/viewing
| experience, whatever that means to that particular editor's
| developer. There's no looming and inevitably unfavorable
| comparison to the format's native editor to have to contend
| with.
| goohle wrote:
| Markdown supports HTML (with JS), and HTML/JS is quite
| powerful. I can make complex computations and drawings with
| JS libraries, then present them nicely with custom CSS.
| Some markdown editors supports embedded HTML/JS in preview,
| which makes them easy to use as IDE. My favorite editor is
| Marker[0].
|
| I suspect that I can write embedable applications in JS and
| load them as libraries in Markdown to perform advanced
| stunts, like in Org mode.
|
| [0]: https://github.com/fabiocolacio/Marker
| gnull wrote:
| Would be funny if someone wrote a language server for org
| mode in elisp on top of emacs and offered all of its
| functionality to the other editors.
|
| But jokes aside, is there something that doesn't let us
| implement a language server for org mode?
| Siira wrote:
| I have this idea attempted. It can work if enough
| engineering is put into it.
| Waterluvian wrote:
| Until this post I had no clue Org Mode wasn't just a part of
| Emacs. It needs a much better name if it wants to be a
| standalone markup.
| Jtsummers wrote:
| Except it's not just a markup format. When connecting it to
| the agenda system in emacs you end up with emacs lisp
| snippets (easily, not always) in your org files. And that's
| just part of the basic usage: %%(org-
| anniversary 2021 11 18) It's been %d years since the
| 50,000th org-mode thread on HN.
|
| Or with org-babel you can have different blocks of code
| interact with and reference each other:
|
| https://orgmode.org/manual/Environment-of-a-Code-Block.html
|
| That's a lot more than markup at this point since you can
| run those inside of org-mode.
| nanna wrote:
| Completely agree. I think there's a continuity between
| the misconception of Org Mode as being just being another
| markup format and Emacs being just another text editor.
| BeetleB wrote:
| > It needs a much better name if it wants to be a
| standalone markup.
|
| It doesn't. There have been failed efforts in standardizing
| the grammar. If they can't even do _that_ , it's clear that
| being standalone is not a goal.
| quanticle wrote:
| >My only complaint is that Emacs is the only text editor that
| fully supports Org Mode. Other editors (e.g. vim, VSCode)
| support it too, with only to an extent.
|
| My concern with org-mode is a superset of that. The only parser
| that fully supports org-mode is the one in org-mode itself. The
| ones not built into org-mode (pandoc, org-ruby, etc) all only
| support a subset of org's features. This makes writing anything
| to share in org-mode more difficult because you have to
| restrict yourself to writing in the subset of org-mode that
| e.g. pandoc supports.
|
| That's why I laughed quietly to myself when I saw that the
| author had written, "Org mode is standardized". Org-mode is
| _exactly_ as standardized as Markdown was when Gruber published
| Markdown.pl. There is one authoritative implementation (org-
| mode 's elisp, Gruber's perl script), and to be "standard", all
| other implementations need bug-for-bug compatibility with the
| authoritative version. The only reason org-mode feels more
| standardized is that, currently, the only practical way to use
| org-mode is with the original implementation, in emacs. No
| doubt the original users of Markdown felt the same way, when
| using markdown.pl to format their blog posts.
| tga wrote:
| In my notes, I put the properties as YAML in a code ('''yaml)
| block starting each heading. Easy to parse and well supported
| by all editors.
| vegai_ wrote:
| >Sometimes I also wonder why Org Mode is not as popular as
| Markdown, the former is far more powerful.
|
| Powerful seems to imply complicated to implement. Same reason
| why markdown is beating asciidoc in everything.
| mmcdermott wrote:
| I wonder if being Docbook oriented hurt Asciidoc. At one
| point, I thought everything, even HTML, went through the
| Docbook toolchain and customizing Docbook is intimidating.
| reidjs wrote:
| I don't like the reliance on emacs. I do a lot of writing on my
| phone and tablet, which have limited emacs support. That adds
| some overhead for my writing, which would distract from the
| main point (writing).
|
| Instead of org mode, I bought a markdown editor for iOS and use
| that. Then I sync the markdown files to my computer using
| iCloud.
| CorrectHorseBat wrote:
| For those who use Android there is Orgzly which can edit and
| org mode files (but not everything I think)
| bananadonkey wrote:
| Orgzly does the job for Android, same workflow you describe
| but with org files.
|
| Even has system-wide note capture via system drawer which
| makes jotting notes and ideas very efficient. Something I
| need to figure out with rofi + org-capture or similar for
| desktop!
| aidenn0 wrote:
| > Sometimes I also wonder why Org Mode is not as popular as
| Markdown, the former is far more powerful.
|
| You can replace "Org Mode" with almost every single markup
| language out there. Markdown was designed from the start as an
| 80% solution, and RST, asciidoc, &c. are all more powerful than
| markdown. For interchange, popularity begets popularity, so it
| would be surprising if the technically best (in isolation)
| solution won.
| tlackemann wrote:
| org-mode appears to be thriving these days, or always was, but
| either way I'm really glad to see.
|
| I only picked up emacs last year after being a die-hard vim user
| for 8+ years and org-mode was a large reason why. I wanted to
| learn how to manage todos and documentation alongside my code -
| it's incredible. Lifechanging.
|
| The only negative is trying to teach others to use this workflow.
| I haven't found a tool yet that can easily transform todos in
| org-mode into something a product manager could use. Exporting to
| HTML makes sharing docs a breeze. Maybe workflow tools are a
| rarer use-case or I just haven't dug far enough.
|
| Either way, org-mode definitely worth learning in 2021
| gpderetta wrote:
| Hum, org has built-in export/publish to (among other things)
| html. You can add inline .css as required. What it is missing?
| tlackemann wrote:
| I'm aware but rereading it was unclear. I more was
| asking/bantering about todos.
|
| Sharing docs via HTML export is great
| aidenn0 wrote:
| I haven't used it in many years, but there were plenty of org-
| mode <something else> two-way sync packages. I used the Trello
| one for a bit long ago.
| [deleted]
| nanna wrote:
| How about org's taskjuggler export?
| tlackemann wrote:
| Ah see! I haven't dug deep enough. Thank you kindly, eager to
| dive into that
| nanna wrote:
| To me it's a great example of why Org can't be compared to
| Markdown.
|
| On the one hand you just have a humanly-readable plain text
| file. On the other it is also a spreadsheet. On the other
| it is also the interface to a complex Gannt chart. Org
| files are multidimensional; Markdown files can merely be
| exported to a variety of formats.
| mhd wrote:
| Once upon a time, I quite enjoyed writing in Perl's POD format.
| It's not really a "hidden" markup language like Markdown or
| (partially) org, but it still had way less overhead than XML or
| BBCode. =head1 This is a major headline
| =head2 And a secondary one. Paragraphs end with
| blank lines, as with many other markup systems.
| And you can use I<emphasize> B<Text> with inline codes,
| including some richer than the usual italics/bold, like
| e.g. for F<filenames.txt>.
|
| Doesn't serve the dual purpose of both being a source of
| translation and being read verbatim without the reader knowing
| that it's a markup language, but honestly, you get used to stuff
| like that easily.
|
| Rebol's MakeDoc also was quite neat, and had a very minimal
| implementation. Man, so much lost potential with that language.
| john-doe wrote:
| I miss Textile.
| vzaliva wrote:
| Many people do not realize that if you put a file named
| README.org in top directory of github project, github web UI will
| render it and show it when project page is displayed.
| zora_goron wrote:
| For all my personal GitHub projects, I've been using a
| `README.org` file instead of the default `README.md`!
| Jtsummers wrote:
| That was actually a reason I never used my sr.ht account. I
| like my README.org files.
| vemv wrote:
| Fairly long-time Emacser/Lisper here. Personally I've never
| bothered mastering org-mode; using Emacs has never been a goal in
| itself for me.
|
| In practice, org-mode in a team context barely scales because:
|
| * it's a practically unparseable language: all interop libs (like
| those found for Clojure, Ruby, Haskell, etc) seem to have severe
| limitations parsing/emitting org-mode.
|
| * Related to the previous point, it means one can't create .org
| files automatedly, from a CI pipeline. This makes it hard to have
| documentation guaranteedly up-to-date, out of a codebase.
|
| * Sooner or later, at least a few people in a team won't be
| exactly org-mode fans (even in all-Emacs teams; I've belonged to
| a few).
|
| * Lastly, github itself doesn't excel at rendering .org files -
| one can still find artifacts.
|
| My take would be that if org-mode works for you - awesome! But
| please consider the impact of introducing it at work. Early
| successes can be deceiving.
| alpaca128 wrote:
| Org-Mode is a great concept but looking at the syntax you can
| see its age.
|
| I think it would be cool to have a format comparable to
| Markdown but with support for a JSON-like object notation that
| supports the linking of any metadata to any part of the text.
| That would make it simpler and let users add their own
| properties which would then be just ignored by other parsers.
|
| The problem with such things is of course that we already have
| what feels like a hundred different Markdown variants, each one
| slightly different and incompatible with the others in some
| way. That is in fact the reason I started using .org in the
| first place as a Vim user (that and the LaTeX code support).
| taeric wrote:
| I cringe at the thought of json.
|
| Org can look cumbersome, but only in documents that I posit
| would be cumbersome in any format.
|
| Though, I suspect that down that road ultimately leads to
| some form of xml with cdata style escapes for thorns.
| skrtskrt wrote:
| you cringe at the thought of json but not xml?
| taeric wrote:
| Honestly, yeah. But mainly because I don't see xml
| getting picked.
|
| Xml is at least a markup language. Json is not. Encoding
| a document with it is terrible. Just look at Jupyter some
| time.
| alpaca128 wrote:
| I never suggested encoding a document in JSON. I would
| use a similar syntax for annotations of text elements.
| Both Markdown and Org support similar things(e.g. tagging
| a heading) but with inconsistent, inflexible syntax. I
| don't think anything beats JSON in that area, definitely
| not XML. Specifically I'd prefer something along the
| lines of JSON5 for the sake of sanity, which is just
| better for human-readable and editable content.
| taeric wrote:
| I don't see what json gets you that a standard delimited
| tag didn't get. Such that org's footnote tags already
| work well here.
|
| Or just... Hyperlinks in general. What would you use json
| to encode that https://foo/baz shouldn't already handle?
| And, if you ack that links are already links, the
| standard of either [display](link) or [[display][link]]
| seems as nice as json could possibly get.
| alpaca128 wrote:
| In Org-Mode you have a separate syntax for footnotes, for
| properties(`#+FOO`), for heading properties(`:FOO:`), for
| results of code executions, for time tracking, and so on.
| You could express all those metadata in one consistent
| notation, as an example JSON which would also be more
| compact and not as clunky.
|
| Hyperlinks and text styling can still be done with the
| usual methods, though I don't quite like how in md/org I
| constantly forget where the label and the url goes in the
| hyperlink syntax. Also some of the text styling could use
| slight modifications to reduce the need for escaping.
|
| I'm not saying Org-Mode lacks major features or anything,
| I'm just the kinda guy who likes to tinker and experiment
| with new ideas.
| taeric wrote:
| Fair. I'm the kind to tinker with the old ideas. :D
|
| I'm not really seeing any benefit that json or the like
| would bring to the table here. I could almost see a
| benefit to not having different ways to make properties,
| but only a little. Since it is basically just a mark that
| is intended to indicate different types of marked up
| text.
|
| As an example, if moved to json, how would you
| distinguish the likes of an example block? Just a json
| header with no closing tag? Or a json header with another
| json close?
|
| I guess, put more directly. Orgmode is a bit of an adhoc
| markup language. The designating tags to start and end a
| block are typically $+BEGIN_FOO and #+END_FOO. With free
| text between them, and a lot of magic from emacs to
| syntax highlight based on FOO. Unless you are just going
| to change to {"BEGIN":"FOO"} and {"END:"FOO"}, with free
| text between, you are forcing human edited text into a
| json field, and that is what makes me cringe. And if that
| is your end goal, {"BEGIN":"FOO"} is actually a chore to
| type and read.
|
| Yes, it composes somewhat nicely such that
| #+NAME: Example #+BEGIN_SRC lisp (+ 3
| 2) #+END_SRC
|
| could be: {"NAME":"EXAMPLE", "BEGIN":
| "src", "lang": "lisp"} (+ 3 2)
| {"END":"src"}
|
| But, quite frankly, that looks worse to me. What is json
| bringing to the table?
| Jtsummers wrote:
| I think GP is suggesting it in other places, like
| replacing: #+STARTUP: indent
| #+OPTIONS: ^:nil
|
| With something more like: { "STARTUP" :
| ["indent"], "OPTIONS" : { "^":null} }
|
| That is, not using it to markup the document proper, but
| to encode all the various metadata bits in a more uniform
| notation.
|
| I disagree that it's less clunky than the present
| situation, but it may be more consistent. I mean, you'd
| still need something to mark that some JSON follows and
| is separate from the other text in the document.
| #+CONFIG: <JSON String>
|
| S-expressions would make more sense, if we're sticking
| with emacs lisp anyways. But would still be clunkier than
| the current system at least for writers. Maybe better for
| people trying to implement org-mode (fully) in other
| systems.
| Siira wrote:
| Emitting org-mode is extremely easy (obviously, or otherwise
| people couldn't write it). I myself have not needed complex
| parsing of them, but simple regexes and perl scripts have
| served my needs. This is especially true when you impose some
| structure on your text.
|
| In the worst case scenario, you should be able to just use the
| elisp code itself to parse the file. There already are
| exporters to most other common formats.
| JoelMcCracken wrote:
| Honestly, I agree. I understand that pandoc can convert to/from
| org files, but I'm sure that conversion is lossy (i don't know
| how it could possibly not be).
|
| I love org mode, but i think its best used by individuals. Now
| maybe if someone decided to standardize it, things would be
| different, but as it stands, don't use it on teams.
|
| However, for your own, personal stuff, i think its great. For
| example I use org-roam to manage my knowledge base. This is an
| inherently personal pursuit so I'm not worried about using it
| for this purpose.
| gpderetta wrote:
| I have used org mode to track team status and generate pretty
| reports and has been reasonably useful.
|
| But what I would want to use it for is literate programming, at
| least for my own personal projects.
|
| Or at the very least as a jupyter notebook replacement (python-
| mode + elpy is already a decent enough replacement ATM).
|
| One day I'll set things up properly.
| bloopernova wrote:
| I keep meaning to work on an JSON to elisp object importer.
|
| I work a fair bit with AWS, and the command line utility can
| output results in JSON. Being able to reference and mess with
| that output in org-babel and org-mode tables would be great.
| bananadonkey wrote:
| I do this for homelab automation using org-babel, it's great.
|
| I am yet to use tangle for anything real like dotfiles or such.
| clircle wrote:
| I think HN is averaging about one high quality Emacs post a week
| these days. Emacs renaissance?
| TOGoS wrote:
| Gigascale software projects with thousands of engineers and a
| hundred layers of abstraction (half of which nobody understands
| and they only work simultaneously 2 days out of the year) got
| everyone burnt out. Messing around in bespoke, home-grown
| computing environments made out of text files that you wrote
| yourself is grounding, like growing your own vegetables, and we
| all need that more than ever these days.
___________________________________________________________________
(page generated 2021-11-18 23:03 UTC)