From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: Graph not hierarchical? Date: Tue, 18 Feb 2014 13:00:22 -0500 Message-ID: <87bny4nvwp.fsf@alphaville.bos.redhat.com> References: <87y51cpsd3.fsf@ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53506) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFoyK-0001EI-9H for emacs-orgmode@gnu.org; Tue, 18 Feb 2014 13:00:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WFoyE-0007NH-Ni for emacs-orgmode@gnu.org; Tue, 18 Feb 2014 13:00:44 -0500 Received: from plane.gmane.org ([80.91.229.3]:39059) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFoyE-0007My-8E for emacs-orgmode@gnu.org; Tue, 18 Feb 2014 13:00:38 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WFoy9-00058r-Rc for emacs-orgmode@gnu.org; Tue, 18 Feb 2014 19:00:33 +0100 Received: from nat-pool-bos-t.redhat.com ([66.187.233.206]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 Feb 2014 19:00:33 +0100 Received: from ndokos by nat-pool-bos-t.redhat.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 Feb 2014 19:00:33 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Brett Viren writes: > Lawrence Bottorff writes: > >> being able to organize and >> extract based on your stuff being stored graph-aware would be nice, >> IMHO. > > I'm by no means an expert on this but I know org-element-parse-buffer > returns a data structure which is a directed-graph. > > http://orgmode.org/worg/org-api/org-element-api.html > > Note, each node has a :parent reference which makes the data structure > circular. Traversing it must take this feature into account. > I thought Lawrence was looking for a way to *impose* a graph structure on his data (stored in an org file, augmented with whatever is necessary to implement his graph(s)). org-element-parse-buffer returns a graph (actually, it's probably closer to a tree) which reflects the *internal* structure of the org document. In some ways, the analogy here is between a Unix file (internal structure: sequence of bytes, operations: open/close/read/write/seek/etc) on one hand, and a structured file: e.g. compiling a program into some intermediate language and storing the result into a file. The file itself doesn't know anything about the structure of its contents: the contents are just a sequence of bytes. But there are tools (compilers, loaders, assemblers, debuggers, etc.) that "understand" the superimposed structure. Similarly here, we have an ordinary org file, but it contains additional stuff that allow other tools to do special things (e.g. cross-link sections of the document into a directed graph). Org itself provides certain mechanisms that *could* be used for that (properties, links) but would not itself "understand" the additional structure. You'd need other tools (probably built on top of org-element-*) to do that. The challenge here is that you can impose structure in a very specific manner, so that both the structure and the tools are only useful in a very specific setting. Or you try to come with generic structure and generic tools that can accommodate a variety of applications. The balance between these two extremes (surgical scalpel vs kitchen sink) is very much a matter of need, taste and experience. That's my understanding - I hope I have not misrepresented the situation too much. -- Nick