From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thorsten Jolitz Subject: Re: Tabular overview of org-element.el Date: Sat, 20 Apr 2013 20:45:53 +0200 Message-ID: <87fvyl3use.fsf@gmail.com> References: <87obd944dk.fsf@gmail.com> <87ip3hnou6.fsf@gmail.com> <87k3nx3yz5.fsf@gmail.com> <87ehe5nlnh.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:49393) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTcnW-0002a6-9C for emacs-orgmode@gnu.org; Sat, 20 Apr 2013 14:46:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UTcnU-0003uf-P5 for emacs-orgmode@gnu.org; Sat, 20 Apr 2013 14:46:06 -0400 Received: from plane.gmane.org ([80.91.229.3]:53905) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTcnU-0003uM-FD for emacs-orgmode@gnu.org; Sat, 20 Apr 2013 14:46:04 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UTcnS-0006eo-Ey for emacs-orgmode@gnu.org; Sat, 20 Apr 2013 20:46:02 +0200 Received: from e178055128.adsl.alicedsl.de ([85.178.55.128]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 20 Apr 2013 20:46:02 +0200 Received: from tjolitz by e178055128.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 20 Apr 2013 20:46:02 +0200 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 Nicolas Goaziou writes: > Thorsten Jolitz writes: > >> Nicolas Goaziou writes: >> >>> Hello, >>> >>> Thorsten Jolitz writes: >>> >>>> I prepared a tabular overview of org-element.el to get a better >>>> understanding of how Nicolas modeled and Org file, and I thought it >>>> might be useful for others so I share it here. >>>> >>>> I did not know where to put 'plain-link', but maybe I simply overlooked >>>> it in one place. >>> >>> It belongs to `org-element-all-successors', which means it is >>> a successor. Actually, it is a dumbed down successor for links, as it >>> only finds plain links, i.e. links with no markup at all. E.g., >>> >>> http://orgmode.org >>> >>> This is necessary as some contexts (i.e. link descriptions) can only >>> contain such links. >> >> >> Whats kind of confusing for me is that all other successors are either >> 'atomic' objects or 'object-categories' containing 'atomic' objects: >> >> ,-------------------------------------------------------------------- >> | Object Recur? Successor(type) SecVal-Location >> | ----------------------------------------------------------------- >> | bold X text-markup >> | code text-markup >> | entity latex-or-entity >> | export-snippet X >> | footnote-reference X :inline-definition >> | inline-babel-call X >> | inline-src-block X >> | italic X text-markup >> | line-break X >> | latex-fragment latex-or-entity >> | link X X >> | macro X >> | radio-target X X >> | statistics-cookie X >> | strike-through X text-markup >> | subscript X sub/superscript >> | superscript X sub/superscript >> | table-cell X X >> | target X >> | timestamp X >> | underline X text-markup >> | verbatim text-markup >> `-------------------------------------------------------------------- >> >> Only plain-link is an 'outlier' in this systematic. What is a link like >> >> ,------------------- >> | http://orgmode.org >> `------------------- >> >> then, when encountered in an Org document? If its not an object nor an >> element, then it is (anonymous) part of the String that forms a paragraph? >> Its easy to understand that some objects can be successors of other >> objects/elements, others not, and that its sometimes convenient to >> organize similar successor objects into successor-categories. >> >> Its not so easy to understand how something can be a successor but not >> an object. > > "http://orgmode.org" _is_ a link object, like [[http://orgmode.org]]. > There are two successors for the same object type, one being more > selective than the other. > > This special successor was introduced (lately) because there was no > image syntax in Org. So we needed to recognize: > > [[http://orgmode.org][./unicorn.jpg]] > > as an image pointing to an URL. In fact, we could separate `plain-link' > objects from `link' objects, but the benefit is not obvious, so > `plain-link' is just considered as a sub-type of `link'. So in fact there are link objects that might belong to 'decorated-link' or 'plain-link', but this has not been made explicit because there is only one special case where its not sufficient to simply use super-type 'link'. Maybe its worth to notice that wrt 'plain-link' there are some hidden implicit things going on in the background. First of all, there are no other subtypes of object-types - object 'link' would be the only object-type with two subtypes ('plain-link' and 'decorated-link' or whatever). And the object 'link' is used as successor but does not fit all situations where a link can be used. I know this might be of no practical relevance at the moment, and might seem like a case of excessive pea-counting, but now that Org-mode has such a wonderful parsing and exporting framework, there might well be a trend towards more formalization in the future - and this will cause hiccups for anyone who tries such formalization. To keep the system consistent, there should be two types of link objects ('plain-link' and 'decorated-link') that are both successors too, and maybe additionally a successor category 'link' that can be applied when distinction between the two link object-types does not matter. -- cheers, Thorsten