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: Sun, 10 Jul 2016 17:41:50 +0300 Message-ID: <83eg71ftch.fsf@gnu.org> References: <87h9cdmj6t.fsf@delle7240.chemeng.ucl.ac.uk> <87eg7f13re.fsf@delle7240.chemeng.ucl.ac.uk> <921c10a04c17462988c2821ed40582e7@DB5PR01MB1895.eurprd01.prod.exchangelabs.com> <87oa6byyud.fsf@ucl.ac.uk> <33003e1e02b04d2db5ee60baff9a040f@HE1PR01MB1898.eurprd01.prod.exchangelabs.com> <87furk71zs.fsf@pinto.chemeng.ucl.ac.uk> <859A313B-96D2-4C06-945A-3275BA2A7C0B@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1468161776 4841 80.91.229.3 (10 Jul 2016 14:42:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 10 Jul 2016 14:42:56 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: chad brown Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 10 16:42:56 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 1bMFwc-0004VR-Up for ged-emacs-devel@m.gmane.org; Sun, 10 Jul 2016 16:42:55 +0200 Original-Received: from localhost ([::1]:55428 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMFwY-00035I-VK for ged-emacs-devel@m.gmane.org; Sun, 10 Jul 2016 10:42:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34807) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMFvy-00034A-Io for emacs-devel@gnu.org; Sun, 10 Jul 2016 10:42:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bMFvu-0007Rx-GD for emacs-devel@gnu.org; Sun, 10 Jul 2016 10:42:14 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56674) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMFvu-0007RX-Ci; Sun, 10 Jul 2016 10:42:10 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2853 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bMFvf-0005ZQ-Ff; Sun, 10 Jul 2016 10:41:56 -0400 In-reply-to: <859A313B-96D2-4C06-945A-3275BA2A7C0B@gmail.com> (message from chad brown on Sat, 9 Jul 2016 23:47:37 -0700) 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:205497 Archived-At: > From: chad brown > Date: Sat, 9 Jul 2016 23:47:37 -0700 > > I do understand that looking at a (long!) list of org-related > packages, or looking at a (similarly long) list of org-related > features, it does seem like (for example) many of those importing or > exporting features could have been general Emacs features instead of > org-specific features. In some of those cases, this is almost > certainly true, but the practice is a bit more nuanced, because > usually those org features are glue between existing Emacs features > and the org structure that makes it easy for everything to work > together inside org (and also work inside Emacs without org). The point I believe Richard is trying to make is that such features should have been designed and implemented differently, in a way that they could be used outside of "Org the note-managing system", and then integrated into Org. > Put another way: there are many parts of Emacs (outside org) that let > one use Emacs to interface with other parts of the world (both import > and export). Org provides a way to put *those* parts together, in a > manner that is both (relatively) simple and coherent. I believe the main issue at hand is with those parts of Org that have no other implementation except as part of Org, and which rely on Org infrastructure for their operation. > *I believe* this is why there’s so much misunderstanding on this > topic: while it’s undoubtedly true that the software design of org > could be improved in hindsight, it’s very hard for the people deeply > involved in the org parts to see how the “glue that lets you combine > many disparate parts into one unifying structured approach” could > (much less “should”) have been designed as separate parts. To give you a trivial example, think about font-lock. Its design allows both Org and any other major mode to do its specialized job of fontifying the buffer. The infrastructure on which font-lock is based is not tied up to any particular mode, but instead is based on general principles, such as the concept of "syntax", which has concrete (and different) expression with each mode. Why couldn't, for example, the "code blocks" feature offered by Org be designed along the same principles? Likewise with exports: the feature could be built around a set of abstract principle, concepts, and APIs, and then each mode could instantiate and customize those according to what it needs.