From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Differences between Org-Mode and Hyperbole Date: Fri, 01 Jul 2016 10:45:14 +0300 Message-ID: <8337ntvm2d.fsf@gnu.org> References: <87h9cdmj6t.fsf@delle7240.chemeng.ucl.ac.uk> <5775A512.4020803@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1467359182 9883 80.91.229.3 (1 Jul 2016 07:46:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 1 Jul 2016 07:46:22 +0000 (UTC) Cc: emacs-devel@gnu.org To: Scott Randby Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 01 09:46:21 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bIt9S-0006sE-Gp for ged-emacs-devel@m.gmane.org; Fri, 01 Jul 2016 09:46:14 +0200 Original-Received: from localhost ([::1]:54304 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bIt9M-0003p1-I8 for ged-emacs-devel@m.gmane.org; Fri, 01 Jul 2016 03:46:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33284) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bIt8q-0003dn-57 for emacs-devel@gnu.org; Fri, 01 Jul 2016 03:45:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bIt8n-0006j4-Fr for emacs-devel@gnu.org; Fri, 01 Jul 2016 03:45:36 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53877) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bIt8n-0006iq-CX; Fri, 01 Jul 2016 03:45:33 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1322 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bIt8l-0005Wq-E5; Fri, 01 Jul 2016 03:45:31 -0400 In-reply-to: <5775A512.4020803@gmail.com> (message from Scott Randby on Thu, 30 Jun 2016 19:02:42 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:205018 Archived-At: > From: Scott Randby > 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.