Re: [O] New exporter, beamer confusion

[Eric S Fraga]

Nicolas Goaziou n.goaz...@gmail.com writes:

 Should there be a check in the exporter, for latex based backends, if
 the document class expected is not defined?  This would have made things
 a lot quicker to resolve in this case!

 What is an expected document class? Beamer export can happen with
 a beamer or an article (and probably others) document class. There's
 no real way to know if the class used is correct.

Sure.  I didn't suggest that there should be a default (although as
others have suggested, a default of beamer would be reasonable).  My
point was simply that generating a latex file with no documentclass
line doesn't make much sense and this omission should be caught by the
exporter.  It would help any user more quickly figure out what is wrong
with the org file being exported.  Well, it would have helped me! ;-)

Arguably, this is not a problem with the beamer exporter but the latex
one instead.

In any case, I'd like to say thanks!  I had a presentation to give
earlier today and wrote it from scratch using the new exporter.  After
the initial hiccoughs (as documented on this list) and my not having
noted earlier that the ATTR_* syntax had changed (e.g. :options
width=... for images), everything went like a charm.

eric
-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org 7.9.3e-904-g338046

Re: [O] New exporter, beamer confusion

[Nicolas Goaziou]

Rasmus ras...@gmx.us writes:

 There is the #+LATEX_HEADER:. Is a keyword specific to Beamer
 required?  It would by symmetric with #+BEAMER: but I have never
 needed it before.


 Something like

 #+LATEX_HEADER:\AtBeginSection[]{\frame{\thispagestyle{empty}\tableofcontents[currentsection]}}

 is not interesting to a LaTeX article output, but perhpas in a Beamer.
 Or it might want to use a more 'fun' font for my slides while sticking
 with kpfonts for the article version, e.g.

 #+BEAMER_HEADER:\usepackage[math]{anttor}
 #+LATEX_HEADER:\usepackage[light]{kpfonts}

 But perhaps (probably!) it could be sorted out on the LaTeX side,
 e.g. via beamerarticle.

I have added BEAMER_HEADER keywords.


Regards,

-- 
Nicolas Goaziou

Re: [O] New exporter, beamer confusion

[Nicolas Goaziou]

 Should there be a check in the exporter, for latex based backends, if
 the document class expected is not defined?  This would have made things
 a lot quicker to resolve in this case!

What is an expected document class? Beamer export can happen with
a beamer or an article (and probably others) document class. There's
no real way to know if the class used is correct.


Regards,

-- 
Nicolas Goaziou

Re: [O] New exporter, beamer confusion

[Vincent Beffara]

Hi, 
 LaTeX class is never unspecified because `beamer' back-end is
 a derivative of `latex', and, as such, `org-latex-default-class' will be
 used. `beamer' could specify its own default class, but that class would
 still need to be defined in `org-latex-classes'.

Sure, it should be in the default list. What is the drawback?
 '(beamer
 \\documentclass[presentation]{beamer}
 \[DEFAULT-PACKAGES]
 \[PACKAGES]
 \[EXTRA]
 (\\section{%s} . \\section*{%s})
 (\\subsection{%s} . \\subsection*{%s})
 (\\subsubsection{%s} . \\subsubsection*{%s}))

Looks reasonable. 
  Plain latex export is more problematic because several options are
  reasonable, but I can't see beamer export with an article class ...
 
 But it exists, and is documented in the Beamer User Guide. See section
 21.2. Creating Handouts Using the Article Mode.

Yes, I know that, but the thing is, from a given org-file, I would expect 
beamer export to make the slides and 'plain' latex export to create the 
handout. Maybe it is difficult to achieve but it feels like the most useable 
setup. Is it at all doable?

/v

Re: [O] New exporter, beamer confusion

[Nicolas Goaziou]

Vincent Beffara vbeffara...@gmail.com writes:

 Sure, it should be in the default list. What is the drawback?

The default list is defined in ox-latex.el, which doesn't know anything
about ox-beamer.el. The drawback is that it doesn't seem clean to me.

I think it's better to make it a fallback value hardcoded (or in
a defconst) in ox-beamer.el instead.

 Yes, I know that, but the thing is, from a given org-file, I would
 expect beamer export to make the slides and 'plain' latex export to
 create the handout. Maybe it is difficult to achieve but it feels like
 the most useable setup. Is it at all doable?

If the author is cautious about keywords used (i.e. #+BEAMER: or
#+LATEX:), it should be possible to export the same document with either
`beamer' or `latex' back-end. Though, I don't know how much difference
there would be between the output from `latex' and a Beamer handout
produced with article class.


Regards,

-- 
Nicolas Goaziou

Re: [O] New exporter, beamer confusion

[Rasmus]

Nicolas Goaziou n.goaz...@gmail.com writes:

 If the author is cautious about keywords used (i.e. #+BEAMER: or
 #+LATEX:), it should be possible to export the same document with either
 `beamer' or `latex' back-end. Though, I don't know how much difference
 there would be between the output from `latex' and a Beamer handout
 produced with article class.


There is an auxiliary package called beamerarticle.  It's neat.  It's
described in 21.2.1 in the beamer guide v.3.26.  And there's an
example in the file conference-ornate-20min.en.tex which is shipped
with beamer.

Cool with the #+BEAMER.  I didn't know about this, but it's super
nice.  The other day I was lookking for a replacement to
#+BEAMER_HEADER (I think that was what it was called), which existed
with the 'old' exporter.  Does this variable exist in Beamer yet?

Thanks a lot for your work Nicolas.  It's super cool!

–Rasmus

-- 
In theory, practice and theory are the same. In practice they are not

Re: [O] New exporter, beamer confusion

[Nicolas Goaziou]

Hello,

Rasmus ras...@gmx.us writes:

 Nicolas Goaziou n.goaz...@gmail.com writes:

 If the author is cautious about keywords used (i.e. #+BEAMER: or
 #+LATEX:), it should be possible to export the same document with either
 `beamer' or `latex' back-end. Though, I don't know how much difference
 there would be between the output from `latex' and a Beamer handout
 produced with article class.


 There is an auxiliary package called beamerarticle.  It's neat.  It's
 described in 21.2.1 in the beamer guide v.3.26.  And there's an
 example in the file conference-ornate-20min.en.tex which is shipped
 with beamer.

 Cool with the #+BEAMER.  I didn't know about this, but it's super
 nice.  The other day I was lookking for a replacement to
 #+BEAMER_HEADER (I think that was what it was called), which existed
 with the 'old' exporter.  Does this variable exist in Beamer yet?

There is the #+LATEX_HEADER:. Is a keyword specific to Beamer required?
It would by symmetric with #+BEAMER: but I have never needed it before.


Regards,

-- 
Nicolas Goaziou

Re: [O] New exporter, beamer confusion

[Rasmus]

Nicolas,

 There is the #+LATEX_HEADER:. Is a keyword specific to Beamer
 required?  It would by symmetric with #+BEAMER: but I have never
 needed it before.


Something like

#+LATEX_HEADER:\AtBeginSection[]{\frame{\thispagestyle{empty}\tableofcontents[currentsection]}}

is not interesting to a LaTeX article output, but perhpas in a Beamer.
Or it might want to use a more 'fun' font for my slides while sticking
with kpfonts for the article version, e.g.

#+BEAMER_HEADER:\usepackage[math]{anttor}
#+LATEX_HEADER:\usepackage[light]{kpfonts}

But perhaps (probably!) it could be sorted out on the LaTeX side,
e.g. via beamerarticle.

–Rasmus

-- 
Vote for proprietary math!

Re: [O] New exporter, beamer confusion

[Rasmus]

James Harkins jamshar...@gmail.com writes:

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

I prefer alert.  See the Beamer manual (texdoc beamer in texlive) on
change of style and how to use alert (e.g. alert on one particular
(sub)slide of a multipage slide).  It's the Beamer way.  Surely it
cannot be a bad thing?

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

Org has many dedicated list symbols namely white space and one of
{[-+*], [0-9][.)]}.  Why should a headline be converted to a list?  It
was always awkward to me.

I don't know how hard it would be to make the default block (of
level 3, say) a list block, but I guess that's ultimately what you
want?  Such a behavior shouldn't be the default, IMO, since a headline
is not a list.


 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.

I'm sure it would be relatively quick to hack together a couple of
regexps and some lisp to do the conversion if you prefer to use the
new exporter.  E.g. find every occurrence of * in the beginning of the
line of length X and convert each occurrence to - with appropriate
white space (e.g. X + N).

What might be useful would be a tag telling Org to use the legacy
exporter on a file basis, although it would also be a short run
solution.

–Rasmus

--
Summon the Mothership!

Re: [O] New exporter, beamer confusion

[Suvayu Ali]

On Wed, Feb 06, 2013 at 01:32:22PM +0100, Rasmus wrote:
 
 I don't know how hard it would be to make the default block (of
 level 3, say) a list block, but I guess that's ultimately what you
 want?  Such a behavior shouldn't be the default, IMO, since a headline
 is not a list.
 

Nested headlines being translated to lists was always a misfeature in
the old exporter.  This was extensibly discussed on the list before
Nicolas implemented the current beamer exporter.  I do not see any
reason to not fix old inconsistent behaviour for the sake of backwards
compatibility.

That said, I think the best way to deal with this is to follow what
Nicolas suggested, mark the subtree and then do `C-c -' to convert these
headlines into lists.  This can be automated to a significant degree by
using keyboard macros or custom lisp.  A well tested keyboard macro can
be easily saved and used as a command.  Since the OP says his old beamer
presentations number in the hundreds, the way I would approach this is
to keep the macro/function handy and convert it if and when these
presentations are required.

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] New exporter, beamer confusion

[Sebastien Vauban]

Hi Rasmus,

Rasmus wrote:
 James Harkins jamshar...@gmail.com writes:

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

 I prefer alert.  See the Beamer manual (texdoc beamer in texlive) on
 change of style and how to use alert (e.g. alert on one particular
 (sub)slide of a multipage slide).  It's the Beamer way.  Surely it
 cannot be a bad thing?

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

 Org has many dedicated list symbols namely white space and one of
 {[-+*], [0-9][.)]}.  Why should a headline be converted to a list?  It
 was always awkward to me.

As a reminder, the conversion of headlines to lists is what daily happens
within common Org files converted to LaTeX documents: just play with the H
option, and you'll see your deeper levels converted to LaTeX lists.

So, this ain't specific to Beamer.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] New exporter, beamer confusion

[Nicolas Goaziou]

Hello,

Eric S Fraga e.fr...@ucl.ac.uk writes:

 Taking your updated version of the example document, I cannot get the
 exporter to generate a latex file that will compile because it is
 missing a documentclass directive.  Is there something else that needs
 to be configured to support beamer, as in maybe org-e-latex-classes?

Indeed. I added it to ox-beamer.el in-file documentation. You need to
add an entry appropriate for Beamer export. This entry doesn't need to
be named beamer. For example, after the merge you add the following to
your init file:

#+begin_src emacs-lisp
'(add-to-list 'org-latex-classes
'(pres
  \\documentclass[presentation]{beamer}
\[DEFAULT-PACKAGES]
\[PACKAGES]
\[EXTRA]
  (\\section{%s} . \\section*{%s})
  (\\subsection{%s} . \\subsection*{%s})
  (\\subsubsection{%s} . \\subsubsection*{%s})))
#+end_src

Then, the following in your buffer will suffice.

  #+latex_class: pres



Regards,

-- 
Nicolas Goaziou

Re: [O] New exporter, beamer confusion

[Nicolas Goaziou]

James Harkins jamshar...@gmail.com 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

Re: [O] New exporter, beamer confusion

[Eric S Fraga]

Nicolas Goaziou n.goaz...@gmail.com writes:

 Hello,

 Eric S Fraga e.fr...@ucl.ac.uk writes:

 Taking your updated version of the example document, I cannot get the
 exporter to generate a latex file that will compile because it is
 missing a documentclass directive.  Is there something else that needs
 to be configured to support beamer, as in maybe org-e-latex-classes?

 Indeed. I added it to ox-beamer.el in-file documentation. You need to

Thanks.  This will indeed help.

Should there be a check in the exporter, for latex based backends, if
the document class expected is not defined?  This would have made things
a lot quicker to resolve in this case!

Thanks again,
eric
-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org 7.9.3e-904-g338046

Re: [O] New exporter, beamer confusion

[James Harkins]

On Feb 7, 2013 3:57 AM, Nicolas Goaziou n.goaz...@gmail.com wrote:
  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.

Ok, and as long as I can configure it, no problem.

Aside Re: Orwell, and now veering well off-topic, his point about passive
voice is that it hides human agency and, in the worst cases, suggests that
something simply is objectively so rather than one or more people made
it so, for reasons that may be subjective, or deflects responsibility à la
mistakes were made. Although the relationship to the present topic is
only tangential, Orwell's caution is at least as relevant today as it was
when he wrote it in 1946. I find for myself that following his advice [6 or
7 rules of thumb at the end of his essay] sounds a little alarm bell when
my thinking is getting sloppy -- so I think it bears repeating. (Apologies
to the scientific authors here, who are trained [oops!] to erase
themselves from reports on their experimental procedures by using passive
voice consistently...)

In fact, it wasn't obvious to me whether it was simply your preference, or
if an expert or authority on slideshow style recommends \alert over
\textbf. In the latter case, I would want to know who and why, so I could
read and then make up my own mind.

  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.

Sure, and that's ok. My frustration stemmed from expecting more
compatibility than there actually is. After adjusting my expectations, I
can figure out how to make it work for me.

hjh

Re: [O] New exporter, beamer confusion

[James Harkins]

On Tue, Feb 5, 2013 at 3:21 PM, Nick Dokos nicholas.do...@hp.com wrote:
 I added a beamer entry to org-e-latex-classes as indicated in

   http://thread.gmane.org/gmane.emacs.orgmode/61497/focus=61536

 (again, I
 have no idea if the sectioning stuff matters or not, and whether it leads
 to problems - improvements/corrections would be welcome):

Made no difference for me.

 Customizing org-e-beamer-environments-extra should do the trick.  I was
 experimenting using the *scratch* buffer, so the following are temporary
 settings, cribbed from those experiments: restart emacs and they
 disappear.

 Something like the following perhaps (very lightly tested - nb: I really
 haven't played with the new exporter very much at all):

 --8---cut here---start-8---
 (setq blockenv '(block b \\begin{itemize}\\item %h \\end{itemize}))
 (add-to-list 'org-e-beamer-environments-extra blockenv t)
 --8---cut here---end---8---

I'm attaching an org file that illustrates a couple of the beamer
formatting options that I used a lot in the old exporter.

1. I *did* use the block environment to emphasize some text by pulling
it out of the itemize bullet lists. If I customize blockenv in org
to render as itemize, then I lose the ability to do this (or, I have
to call block something else).

2. BMCOL (column) layouts are completely ignored.

3. Strong *emphasis* now renders in red, instead of keeping the text's
original color and switching to boldface.

I've also uploaded 3 PDFs to UbuntuOne, the point being to illustrate
how much functionality is lost in the new exporter:

1. Old exporter result
http://ubuntuone.com/2ByUYyYg5wfz07aUuUVPTP

2. New exporter result, without customizing
http://ubuntuone.com/4HSQUoDlZpNHZ46OROZd54

3. New exporter result, with Nick's customization
http://ubuntuone.com/1DnRQultVtdf2OKYjaeSsu


I get the feeling here that the new beamer exporter was written
without a lot of real-world user requirements. Certainly, it's
understandable that HTML, LaTeX article-style and ODT exporters would
be more widely used and more important to get right first. For beamer,
though, I can't reconcile the announcement (Even though the internals
are completely different, the new exporter mostly behaves like its
predecessor. There are only a few noticeable changes) with the fact
that the new beamer exporter is a rather different animal that
completely breaks compatibility with org files written for the old
exporter, and may actually require a complete redo of the org markup
for each file.

I know my emacs-lisp chops are not up to the task of fixing what is
broken in the new beamer exporter. I can supply a couple dozen source
files, to help decide what level of backward compatibility is
feasible. I'm not sure how else I can help.

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). If
that was the intent, then it's not ready for release. Otherwise, I'd
be happy to help draw up an upgrade path for people like myself who
have developed workflows for the old exporter that will eventually not
be supported anymore.

In the meantime, I must stick with the old exporter, though I'll keep
the discussion alive to hash out on the mailing list what needs to be
done to make the new one production-ready for me.

hjh


simple-beamer.org
Description: Binary data

Re: [O] New exporter, beamer confusion

[Eric S Fraga]

Nick Dokos nicholas.do...@hp.com writes:

[...]

 Customizing org-e-beamer-environments-extra should do the trick.  I was

Nick,

thanks for this.  This hint led me to org-e-beamer-select-environment
which, after binding to a key, has allowed me to play sufficiently
enough with the new exporter and beamer that I am now less worried about
the upcoming change in default behaviour!

eric
-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org 7.9.3e-898-gcb1386

Re: [O] New exporter, beamer confusion

[Eric S Fraga]

Nicolas Goaziou n.goaz...@gmail.com writes:


[...]

 Here's an excerpt from ox-beamer.el documentation:

 ;; - Headlines become frames when their level is equal to
 ;;   `org-beamer-frame-level' (or H value in the OPTIONS line).

Nicolas,

I have decided to bite the bullet and try to get all of my beamer files
working with the new exporter.  I have started simply with the
presentation.org file that I had put on Worg for the tutorial on beamer
for the old exporter.

A truncated version of that file (very minimal and attached) fails
completely to export.  I get the following (truncated) error trace:

,
| Debugger entered--Lisp error: (wrong-type-argument buffer-or-string-p t)
|   get-text-property(0 org-props t)
|   org-get-text-property-any(0 org-props t)
|   org-beamer-sectioning(1 t)
|   funcall(org-beamer-sectioning 1 t)
|   (if (and (symbolp (nth 2 class-sectionning)) (fboundp (nth 2 
class-sectionning))) (funcall (nth 2 class-sectionning) level numberedp) (nth 
(1+ level) class-sectionning))
|   ...
|   org-e-latex-headline((headline (:raw-value Introduction :begin 359 :end 
444 ...
`

I have attached the simple test file.

Where am I going wrong?  If I change H:2 to H:1, it works although
obviously the output is not what I want.  Have I misunderstand something
rather fundamental?

Thanks,
eric

-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org 7.9.3e-898-gcb1386
#+TITLE: Writing Beamer presentations in org-mode
#+AUTHOR:Eric S Fraga
#+EMAIL: e.fr...@ucl.ac.uk
#+DATE:  2010-03-30 Tue

#+startup: oddeven

#+LaTeX_CLASS: beamer
#+LaTeX_CLASS_OPTIONS: [bigger]
#+BEAMER_THEME: Madrid
#+OPTIONS:   H:2

# +COLUMNS: %20ITEM %13BEAMER_env(Env) %6BEAMER_envargs(Args) %4BEAMER_col(Col) %7BEAMER_extra(Extra)

* Introduction
** Overview
- org-mode template
- beamer structure
- beamer settings

Re: [O] New exporter, beamer confusion

[Sebastien Vauban]

Hi James,

James Harkins wrote:
 3. Strong *emphasis* now renders in red, instead of keeping the text's
 original color and switching to boldface.

That's because the * are exported as \alert macros in the new exporter
(instead of \textbf in the old one -- for bold face).

As, in the LaTeX's Beamer back-end, you have the ability to either use alert
or bold face, I'd be very happy to do the same from the source Org file,
using:

- `*' for bold (as always),
- `@' for alert (for example[1]).

Though, this is not currently implemented this way, and the default has been
changed between the old and the new exporters.

IIRC, Nicolas' answer was to insert \textbf calls where you want such use of
bold face. Or maybe overwriting one variable which would be the macro used for
translation `*' characters -- but, then, you must anyway use one LaTeX macro
or the other.

Best regards,
  Seb

[1] I think this is Eric Fraga's initial choice of meta-character for alert in
the old exporter (using extra custom code).

-- 
Sebastien Vauban

Re: [O] New exporter, beamer confusion

[Nick Dokos]

James Harkins jamshar...@gmail.com wrote:

 ... 
 
 I get the feeling here that the new beamer exporter was written
 without a lot of real-world user requirements. Certainly, it's
 understandable that HTML, LaTeX article-style and ODT exporters would
 be more widely used and more important to get right first. For beamer,
 though, I can't reconcile the announcement (Even though the internals
 are completely different, the new exporter mostly behaves like its
 predecessor. There are only a few noticeable changes) with the fact
 that the new beamer exporter is a rather different animal that
 completely breaks compatibility with org files written for the old
 exporter, and may actually require a complete redo of the org markup
 for each file.
 
 I know my emacs-lisp chops are not up to the task of fixing what is
 broken in the new beamer exporter. I can supply a couple dozen source
 files, to help decide what level of backward compatibility is
 feasible. I'm not sure how else I can help.
 
 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). If
 that was the intent, then it's not ready for release. Otherwise, I'd
 be happy to help draw up an upgrade path for people like myself who
 have developed workflows for the old exporter that will eventually not
 be supported anymore.
 
 In the meantime, I must stick with the old exporter, though I'll keep
 the discussion alive to hash out on the mailing list what needs to be
 done to make the new one production-ready for me.
 

I'm sure Nicolas is up to his ears in prep work, but eventually I'm sure
he or somebody else who knows more about it than I do, will comment.

Just as a general precaution, I wouldn't rush to judgement based on
my fumbling attempts: these were small experiments done without knowing
anything about the new exporter to begin with. I hope that they did more
good than harm, but it *is* just a hope on my part. Don't mistake them
for authoritative information.

Nick

Re: [O] New exporter, beamer confusion

[Nicolas Goaziou]

Hello,

Eric S Fraga e.fr...@ucl.ac.uk writes:

 I have decided to bite the bullet and try to get all of my beamer files
 working with the new exporter.  I have started simply with the
 presentation.org file that I had put on Worg for the tutorial on beamer
 for the old exporter.

 A truncated version of that file (very minimal and attached) fails
 completely to export.  I get the following (truncated) error trace:

 ,
 | Debugger entered--Lisp error: (wrong-type-argument buffer-or-string-p t)
 |   get-text-property(0 org-props t)
 |   org-get-text-property-any(0 org-props t)
 |   org-beamer-sectioning(1 t)
 |   funcall(org-beamer-sectioning 1 t)
 |   (if (and (symbolp (nth 2 class-sectionning)) (fboundp (nth 2 
 class-sectionning))) (funcall (nth 2 class-sectionning) level numberedp) (nth 
 (1+ level) class-sectionning))
 |   ...
 |   org-e-latex-headline((headline (:raw-value Introduction :begin 359 :end 
 444 ...
 `

 I have attached the simple test file.

 Where am I going wrong?  If I change H:2 to H:1, it works although
 obviously the output is not what I want.  Have I misunderstand something
 rather fundamental?

I have no problem exporting this file. Though, judging from the
backtrace, you're using the old exporter since `org-beamer-sectioning'
comes from it.


Regards,

-- 
Nicolas Goaziou

Re: [O] New exporter, beamer confusion

[Nicolas Goaziou]

Hello,


 I'm attaching an org file that illustrates a couple of the beamer
 formatting options that I used a lot in the old exporter.

See below.

 1. I *did* use the block environment to emphasize some text by pulling
 it out of the itemize bullet lists. If I customize blockenv in org
 to render as itemize, then I lose the ability to do this (or, I have
 to call block something else).

 2. BMCOL (column) layouts are completely ignored.

No. BMCOL are just different.

 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.

 I get the feeling here that the new beamer exporter was written
 without a lot of real-world user requirements.

FWIW, I have used it almost daily since I wrote it.

 Certainly, it's understandable that HTML, LaTeX article-style and ODT
 exporters would be more widely used and more important to get right
 first. For beamer, though, I can't reconcile the announcement (Even
 though the internals are completely different, the new exporter mostly
 behaves like its predecessor. There are only a few noticeable
 changes) with the fact that the new beamer exporter is a rather
 different animal that completely breaks compatibility with org files
 written for the old exporter, and may actually require a complete redo
 of the org markup for each file.

You are half correct. I admit: I forgot to mention that Beamer back-end
was a bit different from its predecessor. Though, it doesn't require
a complete redo, there's just some work to do at the headline level.

 I know my emacs-lisp chops are not up to the task of fixing what is
 broken in the new beamer exporter.

Nothing is broken in it (at least AFAIK). There are just some changes to
do.

 I can supply a couple dozen source
 files, to help decide what level of backward compatibility is
 feasible. I'm not sure how else I can help.

Let's start slowly. I think you can get how to make the changes yourself
with a couple of examples. Since you seem to like lists (you know that
Till Tantau frowns upon the use of third level lists in presentations,
don't you?), the first rule to know is:

  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.

 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.

 If that was the intent, then it's not ready for release. Otherwise,
 I'd be happy to help draw up an upgrade path for people like myself
 who have developed workflows for the old exporter that will eventually
 not be supported anymore.

Thank you. I'll try to help you get started. You might even come to like
the new back-end in the process.

 In the meantime, I must stick with the old exporter, though I'll keep
 the discussion alive to hash out on the mailing list what needs to be
 done to make the new one production-ready for me.

Fair enough.

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

If you use a headline with only a BEAMER_col property, its title will be
ignored and can be used as a container. If you provide it an additional
environment (like block), the new environment will be put in the column
and will fill it. Moreove, the :BEAMER_col: property requires a decimal
number as value, not a length.

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

#+begin_src org
#+LANGUAGE:  en
#+OPTIONS:   H:2 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t :t
#+OPTIONS:   TeX:t LaTeX:t skip:nil d:nil todo:t pri:nil tags:not-in-toc

#+startup: beamer
#+LaTeX_CLASS: beamer
#+LaTeX_CLASS_OPTIONS: [presentation]
#+BEAMER_THEME: default
#+COLUMNS: %45ITEM %10BEAMER_env(Env) %10BEAMER_act(Act) %4BEAMER_col(Col) 
%8BEAMER_opt(Opt)
#+PROPERTY: BEAMER_col_ALL 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 0.0 :ETC

#+TITLE: Testing new beamer exporter
#+AUTHOR:H. James Harkins
#+EMAIL: jamshar...@yaddayadda.com
#+DATE:  7 November 2012

#+BEGIN_LaTeX
\AtBeginSection[] % Do nothing for \section*
{
\begin{frame}beamer
\frametitle{Outline}
\tableofcontents[currentsection]
\end{frame}
}
#+END_LaTeX

* Section A
** Slide 1
   - Third-level
 - Fourth-level
** Ancient history: *Music \emph{n}* languages
   - Early pioneers at *Bell Labs* in New Jersey
 - Max 

Re: [O] New exporter, beamer confusion

[Eric S Fraga]

Nicolas Goaziou n.goaz...@gmail.com writes:


[...]

 I have attached the simple test file.

 Where am I going wrong?  If I change H:2 to H:1, it works although
 obviously the output is not what I want.  Have I misunderstand something
 rather fundamental?

 I have no problem exporting this file. Though, judging from the
 backtrace, you're using the old exporter since `org-beamer-sectioning'
 comes from it.

Which is rather strange although that thought had entered my mind.  I do
not understand how I am ending up in that code when I start the exporter
off with the new dispatcher.  Other files work fine but this one
doesn't.

The funny thing is that if I use the old dispatcher, and hence the old
exporter, it works!

There has to be something in my emacs/org configuration somewhere that
is causing problems.

So I try a minimal example (emacs -Q, set up paths to git org, load in
org-e-beamer) and things get even stranger.  The same org file exports
(no error), but to a latex file that has no document class
definition.  The first (non-comment) line of the latex file is
\usetheme{Madrid}.

I am really confused.  The system is rather fragile, it would seem.

I will continue playing...  although I guess I should try to do some
work as well ;-)

-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org 7.9.3e-897-g787a07

Re: [O] New exporter, beamer confusion

[Eric S Fraga]

Nicolas Goaziou n.goaz...@gmail.com writes:

[...]

 Let's start slowly. I think you can get how to make the changes yourself
 with a couple of examples. Since you seem to like lists (you know that
 Till Tantau frowns upon the use of third level lists in presentations,
 don't you?), the first rule to know is:

[...]

Nicolas,

this email has been quite helpful.  I now see where you have gone with
beamer and overall I like your approach.  However, I *still* cannot get
this to work.

Taking your updated version of the example document, I cannot get the
exporter to generate a latex file that will compile because it is
missing a documentclass directive.  Is there something else that needs
to be configured to support beamer, as in maybe org-e-latex-classes?
The default has no mention of beamer and although the documentation
within org-e-beamer.el does allude to org-e-latex-classes, it doesn't
say whether that variable needs to be adapted/updated/changed.

Having looked at the code, I think I do need to add a beamer entry to
that variable.  Can you please suggest a default that would work?  And
maybe update the documentation or at least output an error message if
the latex class desired is not actually found in org-e-beamer-template?
That function would appear to do nothing if an appropriate entry is not
found and hence explains why I get an exported file with no
documentclass line!

Thanks,
eric

-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org 7.9.3e-897-g787a07

Re: [O] New exporter, beamer confusion

[James Harkins]

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

Re: [O] New exporter, beamer confusion

[Eric S Fraga]

James Harkins jamshar...@gmail.com writes:

[...]

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

#+BEAMER: \setbeamercolor{alerted text}{...some other colour...}

-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org 7.9.3e-897-g787a07

Re: [O] New exporter, beamer confusion

[James Harkins]

Suvayu Ali fatkasuvayu+linux at gmail.com writes:

 On Mon, Feb 04, 2013 at 12:00:08PM +0800, James Harkins wrote:
  #+OPTIONS:   H:10 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t :t
 
 The H:10 is your problem.  Since you want 2nd level headlines to be
 frames, it should be H:2.

Ah. OK, that's an improvement.

Still a problem, though. The old exporter preserves the outline structure under 
the frame level, as nested bullet lists. The new exporter flattens them.

* In:

* Section A
** Slide 1
*** Third-level
 Fourth-level

* Old exporter:

Slide 1
---
- Third-level
-- Fourth-level

* New exporter:

Slide 1
---
Third-level
Fourth-level

Should the new exporter change the appearance of my presentations so much? I'm 
hoping there's an option for this (as redoing the markup for 20 or more sets of 
class slides is... painful to contemplate).

Thanks,
hjh

Re: [O] New exporter, beamer confusion

[Nicolas Goaziou]

Hello,

James Harkins jamshar...@gmail.com writes:

 Suvayu Ali fatkasuvayu+linux at gmail.com writes:

 On Mon, Feb 04, 2013 at 12:00:08PM +0800, James Harkins wrote:
  #+OPTIONS:   H:10 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t :t
 
 The H:10 is your problem.  Since you want 2nd level headlines to be
 frames, it should be H:2.

 Ah. OK, that's an improvement.

 Still a problem, though. The old exporter preserves the outline structure 
 under 
 the frame level, as nested bullet lists. The new exporter flattens them.

 * In:

 * Section A
 ** Slide 1
 *** Third-level
  Fourth-level

 * Old exporter:

 Slide 1
 ---
 - Third-level
 -- Fourth-level

 * New exporter:

 Slide 1
 ---
 Third-level
 Fourth-level

 Should the new exporter change the appearance of my presentations so much? 
 I'm 
 hoping there's an option for this (as redoing the markup for 20 or more sets 
 of 
 class slides is... painful to contemplate).

Here's an excerpt from ox-beamer.el documentation:

;; - Headlines become frames when their level is equal to
;;   `org-beamer-frame-level' (or H value in the OPTIONS line).
;;   Though, if an headline in the current tree has a BEAMER_env
;;   (see below) property set to either frame or fullframe, its
;;   level overrides the variable.  A fullframe is a frame with an
;;   empty (ignored) title.
;;
;; - All frames' children become block environments.  Special block
;;   types can be enforced by setting headline's BEAMER_env property
;;   to an appropriate value (see `org-beamer-environments-default'
;;   for supported value and `org-beamer-environments-extra' for
;;   adding more).

In particular, All frames children become block environments. So in
your example Third-level is a block environment and Fourth-level is
a block within it. There's no flattening going on (look at the tex file
to convince yourself).


Regards,

-- 
Nicolas Goaziou

Re: [O] New exporter, beamer confusion

[James Harkins]

On Feb 5, 2013 3:51 AM, Nicolas Goaziou n.goaz...@gmail.com wrote:
 In particular, All frames children become block environments. So in
 your example Third-level is a block environment and Fourth-level is
 a block within it. There's no flattening going on (look at the tex file
 to convince yourself).

Thanks for pointing me to the comments in the .el source file.

So here's my situation. I have a year's worth of lecture slides that render
nicely using the old exporter. In the new exporter, the clear hierarchies
of enumerate environments disappear, replaced by flat blocks. This new
behavior is not useful to me.

The comments in the source don't say anything about how I can modify the
default block behavior. As a result, if the new exporter is fundamentally
incompatible with the old and the only way is to insert properties by hand
under every headline (across all of my files, I'd guess the count is in the
high hundreds, if not 1000)... then the new beamer exporter is not useful
to me.

Is there an existing feature request for this? If not, would it help if I
logged one? (Even if I didn't have existing files -- I like bullet points
on slides, not flat text. I don't understand why I shouldn't be able to set
that as a global or per-file preference.)

I don't mean to be harsh. I'm glad for the new exporter and I'll use it for
the next article I write. For beamer, though, currently it sounds like a
lot of work to get a result that used to be easy.

hjh

Re: [O] New exporter, beamer confusion

[Nick Dokos]

James Harkins jamshar...@gmail.com wrote:

 On Feb 5, 2013 3:51 AM, Nicolas Goaziou n.goaz...@gmail.com wrote:
  In particular, All frames children become block environments. So in
  your example Third-level is a block environment and Fourth-level is
  a block within it. There's no flattening going on (look at the tex file
  to convince yourself).
 
 Thanks for pointing me to the comments in the .el source file.
 
 So here's my situation. I have a year's worth of lecture slides that render 
 nicely using the old
 exporter. In the new exporter, the clear hierarchies of enumerate 
 environments disappear, replaced
 by flat blocks. This new behavior is not useful to me.
 
 The comments in the source don't say anything about how I can modify the 
 default block behavior.
 As a result, if the new exporter is fundamentally incompatible with the old 
 and the only way is to
 insert properties by hand under every headline (across all of my files, I'd 
 guess the count is in
 the high hundreds, if not 1000)... then the new beamer exporter is not 
 useful to me.
 

Customizing org-e-beamer-environments-extra should do the trick.  I was
experimenting using the *scratch* buffer, so the following are temporary
settings, cribbed from those experiments: restart emacs and they
disappear.

Something like the following perhaps (very lightly tested - nb: I really
haven't played with the new exporter very much at all):

--8---cut here---start-8---
(setq blockenv '(block b \\begin{itemize}\\item %h \\end{itemize}))
(add-to-list 'org-e-beamer-environments-extra blockenv t)
--8---cut here---end---8---

I added a beamer entry to org-e-latex-classes as indicated in

  http://thread.gmane.org/gmane.emacs.orgmode/61497/focus=61536

by just copying the article entry and modifying it slightly (again, I
have no idea if the sectioning stuff matters or not, and whether it leads
to problems - improvements/corrections would be welcome):

--8---cut here---start-8---
(setq beamerclass '(beamer \\documentclass[11pt]{beamer}
  (\\section{%s} . \\section*{%s})
  (\\subsection{%s} . \\subsection*{%s})
  (\\subsubsection{%s} . \\subsubsection*{%s})
  (\\paragraph{%s} . \\paragraph*{%s})
  (\\subparagraph{%s} . \\subparagraph*{%s})))

(add-to-list 'org-e-latex-classes beamerclass t)
--8---cut here---end---8---

That's enough to export your ECM I think - no guarantees for
anything more complicated.

Nick

 Is there an existing feature request for this? If not, would it help if I 
 logged one? (Even if I
 didn't have existing files -- I like bullet points on slides, not flat text. 
 I don't understand why
 I shouldn't be able to set that as a global or per-file preference.)
 
 I don't mean to be harsh. I'm glad for the new exporter and I'll use it for 
 the next article I
 write. For beamer, though, currently it sounds like a lot of work to get a 
 result that used to be
 easy.
 
 hjh
 
 
 
 Alternatives:
 
 

[O] New exporter, beamer confusion

[James Harkins]

During the semester break, I want to switch over to the new exporter.
Currently I'm using export mainly for beamer presentations.

I found the org-e-latex-classes entry in an old e-mail post. With
that, M-x org-export-dispatch l P produces a .tex document that
compiles. But the output is not right.

I've typically done my presentations with sections and frames only, no
sub-(sub-)sections. So I got some improvement over my first test by
removing the subsection lines from Nicolas' example entry:

(add-to-list 'org-e-latex-classes
 '(beamer
   \\documentclass[presentation]{beamer}
\[DEFAULT-PACKAGES]
\[PACKAGES]
\[EXTRA]
   (\\section{%s} . \\section*{%s})
;   (\\subsection{%s} . \\subsection*{%s})
;   (\\subsubsection{%s} . \\subsubsection*{%s})
))

Frame display is still incorrect, though. If I write:

* Section A
** Slide 1
*** Third-level
 Fourth-level

... I expect ** in the outline to be the frame title, and the third
and fourth level headings go into the frame's body as bullets. But in
the .tex file, there is no \begin{frame} at all. So I get an
enumeration hard-aligned to the top of the frame:

1. Slide 1
1.1 Third-level
1.1.1 Fourth-level

Bottom line question, then, is: How can I convert my setup for the old
exporter (pasted below) over to the new exporter, and get compatible
results without having to restructure dozens of org files?

I'm also attaching a very simple org file that I'm using for testing.

Org-mode version 7.9.2 (release_7.9.2-883-g6fb36e.dirty @
/home/dlm/share/org-mode.git/lisp/) (Dirty = A tiny patch I have
submitted for a mobileorg problem, which so far has been ignored.)

hjh

*** OLD EXPORTER SETUP

#+LANGUAGE:  en
#+OPTIONS:   H:10 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t :t
#+OPTIONS:   TeX:t LaTeX:t skip:nil d:nil todo:t pri:nil tags:not-in-toc
#+EXPORT_SELECT_TAGS: export
#+EXPORT_EXCLUDE_TAGS: noexport

#+startup: beamer
#+LaTeX_CLASS: beamer
#+LaTeX_CLASS_OPTIONS: [bigger]
#+BEAMER_FRAME_LEVEL: 2

#+TITLE: Applied Techniques for Digital Audio \newline Making
music by programming
#+AUTHOR:H. James Harkins
#+DATE:  7 November 2012

#+BEGIN_LaTeX
\AtBeginSection[] % Do nothing for \section*
{
\begin{frame}beamer
\frametitle{Outline}
\tableofcontents[currentsection]
\end{frame}
}
#+END_LaTeX

* Section
** Frame
*** Bullet in frame


simple-beamer.org
Description: Binary data


simple-beamer.tex
Description: TeX document

Re: [O] New exporter, beamer confusion

[Suvayu Ali]

On Mon, Feb 04, 2013 at 12:00:08PM +0800, James Harkins wrote:
 #+OPTIONS:   H:10 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t :t

The H:10 is your problem.  Since you want 2nd level headlines to be
frames, it should be H:2.

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.