Re: Differences between Org-Mode and Hyperbole

[Eli Zaretskii <eliz@gnu.org>]

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

Please note that I am an Org user myself, albeit not a heavy user.
When I need to make sense out of many tasks and manage them in a
GTD-like manner, I use Org.  Some of the more serious tasks of my work
on Emacs, such as the bidirectional display, were managed via Org.

But using Org and being fond of it doesn't mean we cannot learn from
its design for the future, and it doesn't mean we cannot decide that
an alternative design could yield a more useful set of feature that
would be easier to learn than what we have now.  It's a legitimate
conclusion, and it doesn't in any way denigrate Org, because a package
design isn't determined solely by its designers, it is determined by
many other factors, like the available time and resources, on which no
one has full control.  Therefore, saying that an alternative design
could yield better results doesn't put any blame on those who worked
on the package, and shouldn't put those people on the defensive.

> The Org community is very open to suggestions for improvement. If anyone 
> has specific suggestions for improvements to Org, instead of vague 
> pronouncements about alleged failures, then please send them to the Org 
> mailing list.

This is exactly what this discussion is NOT about.  Org's design is a
fait accompli, and no one in their right mind will come up with
suggestions to redesign it.  Once again, this is not about some flaw
in Org, it's about design principles of large Emacs packages.

> it appears to me that perhaps incorporating Org into official Emacs
> was the failure

Now, this is uncalled-for, and factually incorrect.