From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tom Newsgroups: gmane.emacs.devel Subject: Re: Differences between Org-Mode and Hyperbole Date: Fri, 1 Jul 2016 20:53:51 +0000 (UTC) Message-ID: References: <87h9cdmj6t.fsf@delle7240.chemeng.ucl.ac.uk> <5775A512.4020803@gmail.com> <8337ntvm2d.fsf@gnu.org> <87h9c9lqll.fsf@ericabrahamsen.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1467406473 7771 80.91.229.3 (1 Jul 2016 20:54:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 1 Jul 2016 20:54:33 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 01 22:54:23 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 1bJ5SB-0004Ep-Fz for ged-emacs-devel@m.gmane.org; Fri, 01 Jul 2016 22:54:23 +0200 Original-Received: from localhost ([::1]:35623 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJ5SA-0007vv-QB for ged-emacs-devel@m.gmane.org; Fri, 01 Jul 2016 16:54:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50777) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJ5S0-0007tr-K5 for emacs-devel@gnu.org; Fri, 01 Jul 2016 16:54:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bJ5Rv-00038f-OI for emacs-devel@gnu.org; Fri, 01 Jul 2016 16:54:12 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:58322) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJ5Rv-000374-Gj for emacs-devel@gnu.org; Fri, 01 Jul 2016 16:54:07 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1bJ5Rp-0003zB-Hi for emacs-devel@gnu.org; Fri, 01 Jul 2016 22:54:01 +0200 Original-Received: from 85-238-80-138.pool.digikabel.hu ([85.238.80.138]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Jul 2016 22:54:01 +0200 Original-Received: from adatgyujto by 85-238-80-138.pool.digikabel.hu with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Jul 2016 22:54:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 28 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 85.238.80.138 (Mozilla/5.0 (Windows NT 6.3; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:205056 Archived-At: Eric Abrahamsen ericabrahamsen.net> writes: > > 1. Document structure and export. The org document structure is already > pretty darn simple, and export "just works". You need some kind of > markup and structure before you can export, and I don't see how Org > could get any simpler, or easier to use. There is way to abstract it, by using a function to retrieve the code to export. So, for example, instead of accessing the text markup directly the code should call some (get-code-for-export ...) function which returns the code pieces, instead of handling org markup directly. This way, the export feature would not be dependent on the specific org markup, because it would be hidden behind the implementation of this function. I don't know org internals, but if the DRY principle is followed then there already should be exactly one place in the code for each specific markup handling, because if the same markup is accessed from two different places then it should already be abstracted out to a function, instead having the same implementation of accessing a specific markup at multiple places. So if DRY was applied then org should already have internal api functions for markup access and manipulations, so the export part of the code should in theory already be separated from the actual org text format, and it could also use some other backend implementation.