Hi Eric, And this is where the challenge lies! The whole point of special blocks is > that org knows nothing of their semantics. They are a "black box" and it > would be difficult to identify export specific elements and general > elements on this basis. >
I partially agree with this just because TIL that the html backend is already exporting special blocks as divs with an appropriate css class. But facilitating powerful backend specific mechanisms to the user that prefer to exploit the advantages of a particular backend, by somehow hindering his/her ability to later export to a different format, that's important too. And, besides backend-specific stuff, don't forget there are user-specific extensions, as mine above, that deliberately sacrifice generality. All this is in the best open-close spirit I would say and org already fully embraces it by its superb backend and filter interfaces. The same than the core parser is exposing a block "special type" it could also expose the block "special argument" as an uninterpreted string for the backend to interpret it. To emphasize this point: I'm not proposing that the core parser understands the arguments to the special block but that it passes opaque content for the backend and/or end user to process. I would have gladly avoided that save-excursion-goto-char-re-search-forwars cruft to focus in parsing a string cleanly passed down by the parser. Notice that, up to this point, I've not proposed any modification to the latex backend. But, to be honest, I see no harm in interpreting this special argument as :options if it's well understood that, by doing so, ability to export to another backends may be compromised. I understand this proposal could be more controversial, tough. So I think it's better to distinctly state the different but related suggestions I made: 1. Mention special blocks in the beamer export documentation as an alternative to subsectioning. 2. Make the core parser pass an :args or similar property as part of the element for the sake of backends providing specific extensions or end users filtering the tree to tailor the syntax to their needs, thus empowering special blocks as an extension mechanism. 3. Make the latex backend interpret this :args property as options for the underlying latex environment. Best regards -- Carlos
