Re: Differences between Org-Mode and Hyperbole

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Scott Randby <srandby@gmail.com>
>> Date: Thu, 30 Jun 2016 19:02:42 -0400
>> 
>> On 06/30/2016 01:58 PM, Richard Stallman wrote:
>> >    > This seems to be a major part of your issue with Org mode.  Could you
>> >    > explain in some detail what you mean specifically by having to learn
>> >    > basic Org mode before seeing what its features are?
>> >
>> > I don't remember -- it was years ago that I took a look at it
>> > and gave up.  I don't have time to revisit it now.
>> 
>> It is hard to take this criticism of Org seriously
>
> This discussion will be much more useful if people would not take it
> as an attack on Org.  In particular, the criticism is not about Org
> from POV of the end user, it's about its design principles.  IOW, the
> real subject of this discussion is how should we design large Emacs
> packages, and Org is just being used as an example, to have some
> context and some concrete instances of the abstract ideas.  See the
> beginning of the discussion.
>
> If people could stop being defensive about Org, and instead think more
> broadly, and perhaps bring some other examples into this discussion,
> we might actually reach some useful conclusions that could help us in
> the future.

Here are a few thoughts in terms of the practical "modularization" of
Org -- whether that actually might happen, or whether this is all just
an abstract for-instance.

1. Document structure and export. The org document structure is already
   pretty darn simple, and export "just works". You need some kind of
   markup and structure before you can export, and I don't see how Org
   could get any simpler, or easier to use. Customizing export gets
   pretty complicated, but customization always does. I don't see how
   (or why) you'd do this part differently.
2. The spreadsheet. Apparently table.el was either too complicated or
   too limiting to be easily used. Probably what should have happened
   here is that table.el should have been improved. There's no intrinsic
   reason why the spreadsheet aspect of Org needs to rely on Org's
   markup, or its major mode. (Though then you start getting into
   something like multiple major modes.)
3. Babel. I don't use this, but it's obviously a really, really powerful
   feature that users cannot find elsewhere. In a sense it *is* multiple
   major modes, done in a very regimented and bounded way. Again, no
   real reason why it needs to be part of Org structure or markup. But
   it would need to be part of *some* markup -- it wouldn't be possible
   without structure. Right now, that structure is Org mode.
4. The agenda. Similar to the spreadsheet and table.el, I think the
   agenda came about because diary.el wasn't doing the trick (I don't
   know the history, maybe someone else will chime in). So again, it's a
   re-working of an existing functionality. The agenda itself is a
   special mode, and there's no reason at all why it needs to be tied to
   Org mode document structure. In fact I've often wanted a way to
   simply inject TODO items programmatically into the Agenda, without
   needing them in Org. I think it would be a great advance to have a
   generalized way of creating TODO data structures (structs or objects,
   maybe) and feeding them to the Agenda. Then Org mode headings would
   simply be one of multiple ways of doing that.

So one observation is, Org got where it is by taking some existing Emacs
libraries, making them easier to use, and allowing them all to coexist
in a single document.

Another is, babel is an interesting take on the problem of multiple
interacting major modes. Not in the HTML/PHP sense, necessarily, but...

Eric