[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Differences between Org-Mode and Hyperbole

From: Scott Randby
Subject: Re: Differences between Org-Mode and Hyperbole
Date: Fri, 1 Jul 2016 14:38:23 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]