From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Harkins Subject: Re: New exporter, beamer confusion Date: Wed, 6 Feb 2013 10:12:05 +0800 Message-ID: References: <20130204063905.GA23614@kuru.dyndns-at-home.com> <87wqun5037.fsf@gmail.com> <6207.1360048864@alphaville> <87fw1ashw5.fsf@gmail.com> Reply-To: jamshark70@dewdrop-world.net Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=e89a8fb201ac5181f304d504daea Return-path: Received: from eggs.gnu.org ([208.118.235.92]:42409) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2vC7-0006js-LF for emacs-orgmode@gnu.org; Tue, 05 Feb 2013 21:57:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U2vC5-0006Yv-1X for emacs-orgmode@gnu.org; Tue, 05 Feb 2013 21:57:07 -0500 Received: from mail-oa0-f46.google.com ([209.85.219.46]:58332) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2uUY-0004I6-OC for emacs-orgmode@gnu.org; Tue, 05 Feb 2013 21:12:06 -0500 Received: by mail-oa0-f46.google.com with SMTP id k1so992962oag.5 for ; Tue, 05 Feb 2013 18:12:06 -0800 (PST) In-Reply-To: <87fw1ashw5.fsf@gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Nicolas Goaziou Cc: jamshark70@dewdrop-world.net, nicholas.dokos@hp.com, emacs-orgmode@gnu.org --e89a8fb201ac5181f304d504daea Content-Type: text/plain; charset=ISO-8859-1 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" 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 --e89a8fb201ac5181f304d504daea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Thanks for all this. I'll look at the new org markup lat= er 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 t= ext's
> > original color and switching to boldface.
>
> Indeed. Strong emphasis in Beamer's jargon is \alert{...} (see Bea= mer
> documentation about it). Letter are so large that \textbf{...} doesn&#= 39;t
> fill the job well enough. I'm not saying that \textbf{...} is usel= ess
> (though I think it), but "alert" was preferred.

Ok. There was something about customizing this on the list j= ust 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 u= se 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 retai= n this aversion to red text to this day.)

Btw, *who* preferred \alert? (Orwell, Politics and the Engli= sh Language: "Never use the passive [voice] where you can use the acti= ve.")

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

> =A0 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 c= hange:
> 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 conv= ert my prior work, this is a good step toward consistency. It was odd, in t= he 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 le= ss 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 act= ually 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 respec= t to the
> > announcement, if the new beamer exporter is intended to be reason= ably
> > 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 confi= guration options and perhaps changing a few minor details of the markup. If= you have to change the org document's structure (e.g., converting head= lines to lists), it isn't backward compatible.

For comparison: Lilypond updates frequently break some detai= ls 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 anymo= re. It's H:... in the
> OPTIONS line.

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

> I'm attaching an updated version of your simple doc= ument. 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 lik= ely to be better here!

Really appreciate the details.

hjh

--e89a8fb201ac5181f304d504daea--