Re: [O] New exporter, beamer confusion

[Nicolas Goaziou]

James Harkins <address@hidden> writes:

> Btw, *who* preferred \alert? (Orwell, Politics and the English Language:
> "Never use the passive [voice] where you can use the active.")

Obviously, me, as the author of the back-end. Org offers only one slot
for "strong emphasis". I had to choose between bold and alert, and so
I did.

> Although I'm not happy about manual intervention to convert my prior work,
> this is a good step toward consistency. It was odd, in the old framework,
> to use headlines for bullet lists and org's numbered lists for numbered
> lists. "An org list becomes an output list" is an easier rule to
> explain.

As explained in this thread, the H:num options item defines a limit
between regular headlines and "low-level" headlines. Low level headlines
are usually turned into lists during export. But, in the Beamer
exporter, it is a better idea to turn them into blocks. Better as in
"closer, by its properties, to an headline".

> Still, I wonder if there is a way to make the new backend less unfriendly
> toward lists. It's an interesting philosophical question: In what cases is
> it better for the tool to adapt to the users' wishes, versus cases where
> the tool should encourage (Are blocks in the result actually better than
> lists? Who says so, and why should I take his or her word for it?)

Nobody is saying that blocks are better than lists in the output. It's
a matter of taste, isn't it? There are also ways to adapt the tool to
your wishes (through hooks, filters, script, macros).
> "Reasonably" for me would mean tweaking some configuration options and
> perhaps changing a few minor details of the markup. If you have to change
> the org document's structure (e.g., converting headlines to lists), it
> isn't backward compatible.

Then, by this definition, it isn't, indeed.

> For comparison: Lilypond updates frequently break some details of backward
> compatibility. So, they ship a "convert-ly" script to handle many of those
> changes automatically.

Even though the required change in our case are rather minimal, they
mostly depend on the user configuration. Hence, I will not attempt to
provide such a script.

But I will provide instructions on how to make the transition, if they
are needed.


Regards,

-- 
Nicolas Goaziou