Re: [O] Tabular overview of org-element.el

[Nicolas Goaziou]

Thorsten Jolitz <address@hidden> 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