From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: Tabular overview of org-element.el Date: Sat, 20 Apr 2013 21:07:10 +0200 Message-ID: <87li8dkom9.fsf@gmail.com> References: <87obd944dk.fsf@gmail.com> <87ip3hnou6.fsf@gmail.com> <87k3nx3yz5.fsf@gmail.com> <87ehe5nlnh.fsf@gmail.com> <87fvyl3use.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:55129) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTd7z-0007Tz-B2 for emacs-orgmode@gnu.org; Sat, 20 Apr 2013 15:07:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UTd7y-000306-A5 for emacs-orgmode@gnu.org; Sat, 20 Apr 2013 15:07:15 -0400 Received: from mail-wi0-x22a.google.com ([2a00:1450:400c:c05::22a]:34339) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTd7y-0002zu-43 for emacs-orgmode@gnu.org; Sat, 20 Apr 2013 15:07:14 -0400 Received: by mail-wi0-f170.google.com with SMTP id l13so2638860wie.5 for ; Sat, 20 Apr 2013 12:07:13 -0700 (PDT) In-Reply-To: <87fvyl3use.fsf@gmail.com> (Thorsten Jolitz's message of "Sat, 20 Apr 2013 20:45:53 +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: Thorsten Jolitz Cc: emacs-orgmode@gnu.org Thorsten Jolitz writes: > 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'. That and the fact that it was introduced very recently. > 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. Actually there is also `radio-link' sub-type. But it doesn't need its own successor function so far. > 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 be honest, I hope that Org will grow a proper syntax for images instead (i.e. without overloading link syntax). Many (most?) text markup languages have one (e.g. Markdown). If it does, the `plain-link' successor becomes useless and the case is closed. > 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. That's what I talked about indeed, but besides consistency, there's not much benefit to do that. I'd rather have images as full-fledged objects, something like: [img:"...."] which could possibly be extended with properties for export: [img:"...." :prop1 val1 :prop2 val2] Regards, -- Nicolas Goaziou