Thanks for all this. I'll look at the new org markup later today. That should help a lot.

On Feb 6, 2013 3:03 AM, "Nicolas Goaziou" <n.goaziou@gmail.com> wrote:
> > 3. Strong *emphasis* now renders in red, instead of keeping the text's
> > original color and switching to boldface.
>
> Indeed. Strong emphasis in Beamer's jargon is \alert{...} (see Beamer
> documentation about it). Letter are so large that \textbf{...} doesn't
> fill the job well enough. I'm not saying that \textbf{...} is useless
> (though I think it), but "alert" was preferred.

Ok. There was something about customizing this on the list just recently. I'll use that. (FWIW, I had to produce a number of *gasp cough choke* PowerPoint shows in my previous job, and they told us not to use red for *anything* unless it really was a four-alarm-fire "you will really screw things up if you ignore this" type of point, and I retain this aversion to red text to this day.)

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

> Since you seem to like lists (you know that
> Till Tantau frowns upon the use of third level lists in presentations,
> don't you?)

I appreciate his contribution to LaTeX, but I'll make my own decisions about style, thanks.

>   Headlines will never, ever, become lists in the new Beamer back-end.
>
> If you want lists, use lists. There's a handy command to do that change:
> mark the subtree you want to change, and use "C-c -".
>
> New back-end is more block friendly than lists friendly.

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.

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?)

> > At least, it would be good to clarify, with respect to the
> > announcement, if the new beamer exporter is intended to be reasonably
> > backward-compatible with the old (with not-too-intrusive tweaks).
>
> It all depends on what you mean by reasonably. You can obtain the same
> output, but there are changes to make in Org files.

"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.

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.

> Oh, yes, and BEAMER_FRAME_LEVEL doesn't exist anymore. It's H:... in the
> OPTIONS line.

Right, covered in an earlier message in this thread. I included it here so you could compile it using the old exporter, for comparison.

> I'm attaching an updated version of your simple document. Besides moving
> subtree to lists, there only other change was at the columns level.

Thanks for this, and the explanation of columns. Actually, I never was really happy with columns in the old backend. It's quite likely to be better here!

Really appreciate the details.

hjh