Re: Differences between Org-Mode and Hyperbole

[Scott Randby]

On 07/01/2016 03:45 AM, Eli Zaretskii wrote:
> > From: Scott Randby <address@hidden>
> > 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.

I have been following the entire discussion closely. It contains a 
direct attack on Org by someone who clearly doesn't even know the basics 
of Org. No other examples were given, and none other than Org have been 
given so far by anyone else. If Org is being used as just one example, 
please give other examples of Emacs packages that don't live up to the 
vague "design standards" that are desired, and explain why these 
packages violate those standards so that we can understand exactly what 
the problem is.

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

Yes, what are those other examples. Please be specific. The statement 
that advocates of Org aren't thinking broadly is false, and it isn't the 
job of Org users to bring other examples into the discussion. I'm not 
concerned about the design of Org because its design is fine and it 
works. Can the design be improved? Obviously. Telling us the design is 
flawed without suggesting how it can be fixed is saying nothing useful.

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

Of course we can learn from the design of Org, but saying that doesn't 
contribute anything to the so-called discussion of design principles. I 
haven't been defensive. Instead, I would like to see specifics. Without 
specifics, then a small number of the comments about Org that have been 
made in this thread are simply uninformed attacks and are therefore 
useless. So someone please fork Org and show us how an alternative 
design is better. We could then compare Org with its fork and see which 
one is better. It would be a great test case for the design principles 
which have yet to be specified.

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

No, the discussion hasn't been about large Emacs packages, it has 
focused on Org. No other packages have been mentioned.

> > it appears to me that perhaps incorporating Org into official Emacs
> > was the failure
>
> Now, this is uncalled-for, and factually incorrect.

I did not mean that Org was unsuccessfully incorporated into Emacs. Such 
a claim would be false. What I meant was that the repeated attacks on 
Org (on this thread and others) from a tiny segment of the Emacs 
community have made some Org users (such as myself and a few of my 
friends) regret the merging of Org into Emacs. From my perspective, the 
incorporation was a failure because a small number of influential people 
clearly do not accept Org and have offered no constructive ways of 
making it better. If I had the technical ability, I would fork Org and 
start another project outside of Emacs.

> .