Re: Differences between Org-Mode and Hyperbole

[chad brown]

> On 09 Jul 2016, at 09:56, Richard Stallman <address@hidden> wrote:
> […]
> That seems like a very high-power form of usage.
> I think the fraction of users who would do things like this
> must be rather small.


Org is primarily a system for taking and managing notes in Emacs
(especially but not exclusively structured notes like task lists and
instruction steps). People use it for outlines (from whence it was
born), but also for research notes, papers, and books, among other
things.

Over the years, it has grown extra support for things like exporting
to various presentation formats like PDF, print, and the web; for
including marked-up, live, and/or runnable “chunks” of types other
than plain text (live-calculating tables, runnable code examples,
live-computed graphs from external sources); and for importing (called
“capturing”) bits from external sources like web browsers and PDFs.
Each of these extra pieces was added to address a desire to manage
more things using Emacs.

I do understand that looking at a (long!) list of org-related
packages, or looking at a (similarly long) list of org-related
features, it does seem like (for example) many of those importing or
exporting features could have been general Emacs features instead of
org-specific features. In some of those cases, this is almost
certainly true, but the practice is a bit more nuanced, because
usually those org features are glue between existing Emacs features
and the org structure that makes it easy for everything to work
together inside org (and also work inside Emacs without org).

Put another way: there are many parts of Emacs (outside org) that let
one use Emacs to interface with other parts of the world (both import
and export). Org provides a way to put *those* parts together, in a
manner that is both (relatively) simple and coherent.

*I believe* this is why there’s so much misunderstanding on this
topic: while it’s undoubtedly true that the software design of org
could be improved in hindsight, it’s very hard for the people deeply
involved in the org parts to see how the “glue that lets you combine
many disparate parts into one unifying structured approach” could
(much less “should”) have been designed as separate parts.

I hope that helps,
~Chad