From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Joost Kremers Newsgroups: gmane.emacs.devel Subject: Re: Differences between Org-Mode and Hyperbole Date: Sat, 02 Jul 2016 11:00:14 +0200 Message-ID: <87inwoifdt.fsf@fastmail.fm> References: <83k2h5tbtv.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1467450088 8629 80.91.229.3 (2 Jul 2016 09:01:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 2 Jul 2016 09:01:28 +0000 (UTC) Cc: Scott Randby , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 02 11:01:16 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 1bJGnb-0001SF-Li for ged-emacs-devel@m.gmane.org; Sat, 02 Jul 2016 11:01:15 +0200 Original-Received: from localhost ([::1]:37456 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJGna-0005FS-Kc for ged-emacs-devel@m.gmane.org; Sat, 02 Jul 2016 05:01:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55670) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJGmz-0005FC-VJ for emacs-devel@gnu.org; Sat, 02 Jul 2016 05:00:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bJGmy-0002Cs-Lk for emacs-devel@gnu.org; Sat, 02 Jul 2016 05:00:37 -0400 Original-Received: from out3-smtp.messagingengine.com ([66.111.4.27]:48366) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJGms-00029K-05; Sat, 02 Jul 2016 05:00:32 -0400 Original-Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 3FE4F20342; Sat, 2 Jul 2016 05:00:17 -0400 (EDT) Original-Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Sat, 02 Jul 2016 05:00:17 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=m41CrflOdE647UV0 k6YmUAdBLqI=; b=Bka8h5mx11SwDhG0pm0h8p+7V/XRFvnQjs9IC8cdt7so+j7D tKWrjHozhok1avBjecbLjcGTtQSFIlZzg0bH380x6HqM0fH6fKlTgUlaqIJu2eph Im3pUDfG6FSFPld2asZcsRHmrYv6KWxhfUl9UZF5WyZ8SvNnNDZr9T31TOI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:subject:to:x-sasl-enc:x-sasl-enc; s= smtpout; bh=m41CrflOdE647UV0k6YmUAdBLqI=; b=L8UAUOTXZiU1nxMmu3CA F2XdnXRT1CKIL4oTLfT1WzxPy849hQaMtKQHcSUZWGqyXUxYt9jE1bLskZEVFIss jiUmi60O1R7lkGl4HUKpjS4ahTTg0wqxHEGSgOO/vt3OhXutcNVTInG6TfKJ0NmI PcI4/OfKdaGsWWX6RszMwYI= X-Sasl-enc: YBlFlOh2aF6dxAaxI/VaCrztuCy99CtifHGMJtg3N1n1 1467450016 Original-Received: from IdeaPad.messagingengine.com (x4d0aa3bc.dyn.telefonica.de [77.10.163.188]) by mail.messagingengine.com (Postfix) with ESMTPA id 40E34F29F4; Sat, 2 Jul 2016 05:00:16 -0400 (EDT) User-agent: mu4e 0.9.17; emacs 25.0.94.1 In-reply-to: <83k2h5tbtv.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 66.111.4.27 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:205080 Archived-At: On Fri, Jul 01 2016, Eli Zaretskii wrote: > I tried to give a few specific examples up-thread. I had started a reply to that message but got side-tracked and never finished it. The TL;DR is that there are aspects of Org that I suspect can't really be separated out, there are aspects that probably could and there are aspects that already are. (So the situation isn't as bad as one might think after reading this thread.) The longer version: exporting (your first example) would probably be difficult to separate from Org mode. Although Org files are essentially just plain text files, in order for the exporters to know which parts of the text are headers, which are lists, which phrases need to be set in italic or bold, etc. etc., the source file needs some markup, and this markup happens to be Org's markup. (Personally, I would have preferred something Markdown-based, but that's just me. Currently, it *is* possible to change the visual appearance of markup elements in Org, so you can define *text* to appear as italic instead of bold, but the exporters ignore such configurations, unfortunately.) In order to separate the exporters from the actual markup, you'd need something similar to Pandoc[1], which has an internal (markup-independent) representation of a document's structure and can therefore translate X different markup languages into Y different markup languages, but AFAIK Org doesn't have such an internal representation, so the exporters need to rely on the markup itself. For other parts of Org (I think you also mentioned Babel), it would probably be easier to convert them into minor modes that aren't dependent on Org (or on the file they're used with being an Org file). In fact, this has already been done for at least one feature: table editing. There's an orgtbl-mode that provides Org's table editing facilities and that can be used outside of org-mode. (I use it occasionally in Markdown files, for example). I think there's also orgstruct-mode or something similar, a minor mode that provides Org's structure handling in non-Org files (i.e., headers and lists). The agenda (another example that came up here) is very much bound to Org if only because the agenda information (appointments, deadlines, etc. etc.) are stored in Org files. But that could of course be hidden from the user entirely, if so desired. In sum, although I know little about Org's internals, I guess it should be possible to turn Org into a small base system containing the major mode, combined with a number of minor modes that provide additional functionality, which are not tied directly to org-mode itself. Such a design might even benefit Org mode itself, because not every Org user uses all features. I haven't got a clue as to the amount of work that would be involved, though, to turn Org into such a modular system. Footnotes: [1] http://www.pandoc.org -- Joost Kremers Life has its moments