Re: Differences between Org-Mode and Hyperbole

[Achim Gratz <Stromeko@nexgo.de>]

Eli Zaretskii writes:
> It [Org] includes several features that are very loosely coupled.

The coupling of these features is via Org the document format, not Org
the major mode.  This document format used to be whatever Org chose to
interpret some piece of text as, but is now more formally specified and
the implemented as a parser (org-element) in elisp.  There are probably
still parts of Org that work directly on the text, but they're on the
way out.

> E.g., what does spreadsheet-like table have to do with
> outline-structured notes?

That people writing an outline expect the ability to include tables
without needing to get out of the document they're editing?  That it's
vastly easier to maintain these tables when you can do the calculations
right there?  BTW, org-table uses Calc and there's enough of an API to
use it from outside Org if you wanted to.  In fact, if anybody really
wants to separate out something from Org, then the spreadsheet is a
pretty obvious candidate.  Keeping a separate spreadsheet working from
within Org will be a non-trivial exercise, though.

> What does the ability to embed source code in several programming
> languages has to do with diary features?

See above.  Again, these are provided by Org because that's what users
expect to do from within their Org documents.  It doesn't prescribe
implementation within Org.

> Sure, we can come up with use cases where it makes sense to use these
> features together in the same file, but I think use cases where they
> are unrelated are much more abundant.

Cases of using a computer that do not involve the Emacs are also
abundant, I hope you agree that this as not an argument against Emacs.

[…]
> Once again, this is explicitly NOT about the user POV.  It is beyond
> any argument that Org is a very successful package, as far as its
> users are concerned.  So let's not bring this issue into this
> discussion, it is not relevant here.

Then why do keep mentioning use cases and features, which are inherently
user-centric?  It should tell you something that you are unable to keep
the discussion going without resorting to user issues and indeed I think
you shouldn't be trying.  Emacs is about users getting things done first
and about Emacs developers spending their time efficiently second.

> Btw, it might be relevant to point out that quite a few features
> originally provided by Gnus were over the years refactored into
> separate Emacs packages, and are nowadays available in general-purpose
> subdirectories, like lisp/net, lisp/mail, and others.  Perhaps the
> most prominent example is Message mode, which was several years ago
> made the default Emacs mail composing mode.  This tendency continues
> with Gnus to this day.  My interpretation of that is that Gnus, too,
> had/has some features included that shouldn't have been there in the
> first place _as_part_of_Gnus_.

Hindsight is 20/20.  I could claim plausibly enough that separating
message out from GNUS from the outset would have stalled development of
both Gnus and message.  But in fact both these interpretations are
unprovable and of questionable utility to the future of different
packages already in Emacs like Org or new ones coming in like Hyperbole.

[…]
> As I said already several times, there's no "digging" here.  This is a
> discussion about design principles of large Emacs packages.

I've yet to see that discussion starting.  Emacs would need a way to
specify API, indicate various degrees to indicate whether they are
internal or external or how stable they can expected to be and backwards
compatibility to the public API of at least the immediately prior major
API version before the componentization of Emacs as alluded to in this
thread can take off on a larger scale.

> Well, here's where we disagree.  Tight integration of unrelated
> features is not a good thing, IMO, since it makes learning each one
> harder, and it makes maintenance more vulnerable to a loss of a single
> central individual who knows all the ins and outs.

More user POV, which you said was irrelevant.  Just because one file has
an "org-" prefix doesn't necessarily mean "tight integration" in the
design principles sense either.  I personally don't use the agenda for
instance and the fact that org-agenda.el exists is irrelevant to my
daily work.  Org doesn't care much either, it could just as well import
some Emacs facility in that same place if one was existing.  Despite
allusions to the contrary, org-agenda also doesn't replace existing
Emacs facilities, most of it is customization and UI, but the bulk work
is done via calendar.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

DIY Stuff:
http://Synth.Stromeko.net/DIY.html