Thorsten Jolitz <tjol...@gmail.com> 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