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: Sat, 02 Jul 2016 10:05:15 +0300 Message-ID: <83eg7ctt90.fsf@gnu.org> References: <87h9cdmj6t.fsf@delle7240.chemeng.ucl.ac.uk> <5775A512.4020803@gmail.com> <8337ntvm2d.fsf@gnu.org> <5776B89F.60704@gmail.com> <83k2h5tbtv.fsf@gnu.org> <5776E1F4.3020709@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1467443152 12724 80.91.229.3 (2 Jul 2016 07:05:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 2 Jul 2016 07:05:52 +0000 (UTC) Cc: emacs-devel@gnu.org To: Scott Randby Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 02 09:05: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 1bJEzq-0001lz-5N for ged-emacs-devel@m.gmane.org; Sat, 02 Jul 2016 09:05:46 +0200 Original-Received: from localhost ([::1]:37206 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJEzp-0005l8-5d for ged-emacs-devel@m.gmane.org; Sat, 02 Jul 2016 03:05:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44462) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJEzg-0005kH-Ul for emacs-devel@gnu.org; Sat, 02 Jul 2016 03:05:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bJEzc-00067F-R5 for emacs-devel@gnu.org; Sat, 02 Jul 2016 03:05:36 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48468) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJEzc-000674-Mj; Sat, 02 Jul 2016 03:05:32 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2185 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bJEzZ-0002N6-NN; Sat, 02 Jul 2016 03:05:31 -0400 In-reply-to: <5776E1F4.3020709@gmail.com> (message from Scott Randby on Fri, 1 Jul 2016 17:34:44 -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:205075 Archived-At: > Cc: emacs-devel@gnu.org > From: Scott Randby > Date: Fri, 1 Jul 2016 17:34:44 -0400 > > > Having just one example in a discussion doesn't constitute an attack > > on that single example. > > Again, what are other examples? Why do we need more? An idea can be explained using a single example. > If Org is the only example, then what makes it different from all > the other Emacs packages? It includes several features that are very loosely coupled. E.g., what does spreadsheet-like table have to do with outline-structured notes? What does the ability to embed source code in several programming languages has to do with diary features? Sure, we can come up with use cases where it makes sense to use these features together in the same file, but I think use cases where they are unrelated are much more abundant. > If there are more examples, then what is it they have in common so > that a design philosophy can be developed that is universally > useful? An argument in a discussion doesn't have to move from examples to their generalization. It can do it the other way around: first state a principle or an idea, and then illustrate it with a single example. Both methodologies are valid and are widely used. > I could spend all day being critical of Gnus, but I've never been able > to figure out how to use it so I don't have any legitimate reason to > present my uninformed opinion about it. Once again, this is explicitly NOT about the user POV. It is beyond any argument that Org is a very successful package, as far as its users are concerned. So let's not bring this issue into this discussion, it is not relevant here. Btw, it might be relevant to point out that quite a few features originally provided by Gnus were over the years refactored into separate Emacs packages, and are nowadays available in general-purpose subdirectories, like lisp/net, lisp/mail, and others. Perhaps the most prominent example is Message mode, which was several years ago made the default Emacs mail composing mode. This tendency continues with Gnus to this day. My interpretation of that is that Gnus, too, had/has some features included that shouldn't have been there in the first place _as_part_of_Gnus_. > > Besides, I think the fact that Richard was turned off by Org so early > > in his attempts to learn it should tell us something important. > > Richard cannot be accused of being an Emacs outsider, or of not being > > capable of learning complex Emacs stuff. > > Yes, it says that Richard doesn't know how to use Org. I think it tells us much more than that. > > AFAIU, this discussion was meant for Emacs developers, not for Org > > users/advocates. The suggestion to think broadly was aimed at all of > > us, not just for those who think Org was designed in the best way > > possible. Think broadly in this context means think about more than > > just Org. > > I'm sorry I said anything since I'm not an Emacs developer. But I never > claimed that Org was designed in the best way possible. Yes, I care more > about Org than other packages because I use Org for almost all of my > work, it is a fantastic tool. I'm just tired of these digs at Org from > people who don't use it. As I said already several times, there's no "digging" here. This is a discussion about design principles of large Emacs packages. > > AFAIU, Richard's comment was that the design principles were wrong, > > not that the design itself was flawed. The main design principle in > > question is that of tight integration between unrelated parts of a > > large package. > > Though I'm not an Emacs or an Org developer, I have to disagree > slightly. The tight integration between pieces of Org is one of the > features that makes it so useful. Well, here's where we disagree. Tight integration of unrelated features is not a good thing, IMO, since it makes learning each one harder, and it makes maintenance more vulnerable to a loss of a single central individual who knows all the ins and outs.