Re: [POLL] Naming of "export features"

["Sébastien Miquel" <sebastien.miquel@posteo.eu>]

Ihor Radchenko writes:
> Only the simplest cases of prepending/appending staff.
> If we want to splice into the normal export template, users currently
> must either write an output filter or rewrite the trnascoders
> completely.
>
> The proposed template system will provide more flexibility to modify the
> default export transcoders.

Reading your original proposal, I see nothing that provides more
flexibility. I can guess at how it would allow one to prepend/append
stuff to the output of the default transcoder. Anything more flexible
than that would require breaking these default transcoders into parts,
which you did not originally mention.

>> Here's a couple interesting examples that currently cannot, I think.
>>    + a `multicol` heading property, that wraps the content of the
>>      heading in a multicol environment.
> Could you please illustrate with examples?

Exported content would be:
#+BEGIN_SRC latex
\section{ABC}
\begin{multicols}{3}
   Section content
\end{multicols}
#+END_SRC

>>    + a `nocontent` property that do not export the content of the
>>      heading
> This can be done with :filter-parse-tree or :filter-headline

I guess. This isn't "couple of lines"-easy though.

>>    + Some way to play with the numbering of section, beyond the
>>      `unumbered` property.
> Could you elaborate what kind of "play" you are referring to?

I cannot think of anything that cannot be achieved through (somewhat
fragile) post-processing with `:filter-headline`.

Anyway, I was only trying to understand if your proposal could easily
do these things. What flexibility does it bring ?

>> It is indeed unfortunate that org doesn't provide an easy way to get
>> this behaviour, and achieving it would require the fragmentation
>> (templating ?) of at least some transcoders. I'm not sure that it
>> makes sense to do this for anything other than the headings
>> transcoders, and the main template.
> Currently, transcoders are opaque functions that expose a limited number
> of pre-defined settings. Turning them into templates will allow certain
> non-standard alternations that we cannot think of in advance. Without
> directly modifying the transcoder function code.
>
>> However, this seems orthogonal to your previous proposal. It is not
>> clear to me how it ties with your syntax.
> Could you elaborate?

See higher. More flexibility requires breaking up some transcoders
into pieces. AFAIU it, the proposal you originally described does not
bring any more flexibility beyond what can be done through short
advices, or indeed the `:filter-` functions. I'm not sure this
dedicated syntax is preferable to advices.

-- 
Sébastien Miquel