Re: Differences between Org-Mode and Hyperbole

[Eli Zaretskii]

> From: chad brown <address@hidden>
> Date: Sat, 9 Jul 2016 23:47:37 -0700
> 
> 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).

The point I believe Richard is trying to make is that such features
should have been designed and implemented differently, in a way that
they could be used outside of "Org the note-managing system", and then
integrated into 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 the main issue at hand is with those parts of Org that have
no other implementation except as part of Org, and which rely on Org
infrastructure for their operation.

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

To give you a trivial example, think about font-lock.  Its design
allows both Org and any other major mode to do its specialized job of
fontifying the buffer.  The infrastructure on which font-lock is based
is not tied up to any particular mode, but instead is based on general
principles, such as the concept of "syntax", which has concrete (and
different) expression with each mode.

Why couldn't, for example, the "code blocks" feature offered by Org be
designed along the same principles?

Likewise with exports: the feature could be built around a set of
abstract principle, concepts, and APIs, and then each mode could
instantiate and customize those according to what it needs.