From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Scott Randby Newsgroups: gmane.emacs.devel Subject: Re: Differences between Org-Mode and Hyperbole Date: Fri, 1 Jul 2016 14:38:23 -0400 Message-ID: <5776B89F.60704@gmail.com> References: <87h9cdmj6t.fsf@delle7240.chemeng.ucl.ac.uk> <5775A512.4020803@gmail.com> <8337ntvm2d.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1467398327 15827 80.91.229.3 (1 Jul 2016 18:38:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 1 Jul 2016 18:38:47 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 01 20:38:47 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 1bJ3Ku-0002Qx-03 for ged-emacs-devel@m.gmane.org; Fri, 01 Jul 2016 20:38:44 +0200 Original-Received: from localhost ([::1]:35178 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJ3Kt-0006w2-3M for ged-emacs-devel@m.gmane.org; Fri, 01 Jul 2016 14:38:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51909) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJ3Km-0006vn-2Q for emacs-devel@gnu.org; Fri, 01 Jul 2016 14:38:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bJ3Kc-0005NE-SQ for emacs-devel@gnu.org; Fri, 01 Jul 2016 14:38:35 -0400 Original-Received: from mail-it0-x22f.google.com ([2607:f8b0:4001:c0b::22f]:38103) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJ3Kc-0005N8-Lw; Fri, 01 Jul 2016 14:38:26 -0400 Original-Received: by mail-it0-x22f.google.com with SMTP id h190so23589348ith.1; Fri, 01 Jul 2016 11:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=uxyUwpzQpsmfD+oBU/GZZfxUIuaREu+7mVtGX3NK6Zc=; b=crK5e/ZgwUieIckdIJ6rKWWgGbrLNq+fIUhkZ5NV0Xqhb7CixEOTy6pX1cgSRm+RCM hxqDSwZcJHa0h/OCW23uGV7L8j4rkCQOwBcj3/dV5DMDfcaPUzzoj2dbbLCV2lMgFWmc DPm0PtzlhUBI8ga+hK4O7/zLhoxyTXHOzdcMVlRGzT0YiN37XTV2Sk7WQsGtbQ5fC1ZF tQBs0EL//OPg8RTKD3Qm+N8VjPUsgxUQAGtzPQ3Yh6m9GrHwykV37cp5A62iL5VN4PxM lEU9zlqIsZE01etiW4GzCSLkOTs1cnifn0dPPm0+JlNYhvkzzBwkIPE1QK82DocrO5oa yypQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=uxyUwpzQpsmfD+oBU/GZZfxUIuaREu+7mVtGX3NK6Zc=; b=D8WPkWDnnxHN2jr6NFg+OxbSHV26fSZtSPjp3YylV5bjbckPBwKLvNyFKZiGJpysPy 40E3RND5SfwbxJA4jvkMBxVBd4Yqff2bivZ7BbZLeNFSlQ9+DbYnk6vCxcn5xCzZNhiF UuWOSI2kPyurzYm0WbjIGYjpgmCOa2cAyiRRcw4HW3Htf2iIOP4mf27TZlKe8/o6eFLE hEQ6ndyFVfs8wYWfoOJO/KHRm8CqrFFXghDVM3vfki1kWA3MkBRNcKu1M/Bu7u9DB83O 9EjUlSx5agpAJ7d8a/kqd1Ts7Soj6vTDHYa5Rgy5HMioRDeRdPl5jSkAAkiPOn/yIBGY fsgw== X-Gm-Message-State: ALyK8tJupPw/Vg6Yu7tdJ1GmG0srFhI2K9xrB6nSOrjxNZjCte5ix14/83F1Exnsbw1J4w== X-Received: by 10.36.88.81 with SMTP id f78mr1077086itb.36.1467398305659; Fri, 01 Jul 2016 11:38:25 -0700 (PDT) Original-Received: from [192.168.1.103] (cpe-184-56-99-2.neo.res.rr.com. [184.56.99.2]) by smtp.gmail.com with ESMTPSA id i13sm5899559ita.18.2016.07.01.11.38.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jul 2016 11:38:24 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 In-Reply-To: <8337ntvm2d.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:4001:c0b::22f 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:205049 Archived-At: On 07/01/2016 03:45 AM, Eli Zaretskii wrote: >> 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. 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. > . >