Re: Differences between Org-Mode and Hyperbole

[Marcin Borkowski <mbork@mbork.pl>]

On 2016-07-01, at 09:45, Eli Zaretskii <eliz@gnu.org> wrote:

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

Well said.  I agree that Org could be designed much better internally.
OTOH, I feel that the criticism might have been taken better if it had
been founded in at least rudimentary knowledge of Org.

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

+1.

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

Actually, I'd agree with that: Emacs release cycle is much longer than
Org's, and quite a few problems on Org's ML are results of mixing
included and installed versions of Org.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University