[dev] About a beamer back-end

[dev] About a beamer back-end

[Nicolas Goaziou]

Hello,

As I announced in another thread, I'm starting a Beamer back-end for the
new export engine.  Though, before I start hacking, I have a question
about environments.

I'm wondering if it is really interesting to have every environment set
up from headlines. I understand it allows to use column view but, from
my experience, I've used previous Beamer exporter without ever resorting
to this view.  Also, it introduces some hacks (like the "normal" block)
when you want to insert some text after a block.

On the other hand, I think special blocks could be used for
environments.  For example:

#+begin_src org
* Vocabulary
  
  #+ATTR_BEAMER: :title "Definition"
  #+BEGIN_BLOCK
  A *set* consists of elements.
  #+END_BLOCK

  Some text.

  #+ATTR_BEAMER: :title "Question." :action "<2->"
  #+BEGIN_ALERTBLOCK
  Let R be the set of all sets that are not members of themselves.
  Is R a member of itself?
  #+END_ALERTBLOCK
#+end_src

would result in:

#+begin_src latex
\begin{frame}
\frametitle{Vocabulary}
\begin{block}{Definition}
A \alert{set} consists of elements.
\end{block}

Some text.

\begin{alertblock}<2->{Question}
\end{alertblock}
\end{frame}
#+end_src

Beamer minor mode would provide templates for blocks instead of
shortcuts for property API.  Frames would still be defined from
headlines.

I do not mind keeping previous implementation, but it can be clunky at
times. What do you think?


Regards,

-- 
Nicolas Goaziou

Re: [dev] About a beamer back-end

[suvayu ali]

Hi Nicolas,

First a big thank you for all your efforts over the last year.

On Fri, Jun 15, 2012 at 5:08 PM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
>
> I'm wondering if it is really interesting to have every environment set
> up from headlines. I understand it allows to use column view but, from
> my experience, I've used previous Beamer exporter without ever resorting
> to this view.  Also, it introduces some hacks (like the "normal" block)
> when you want to insert some text after a block.
>
> On the other hand, I think special blocks could be used for
> environments.  For example:

[...]

>
> I do not mind keeping previous implementation, but it can be clunky at
> times. What do you think?

I have to agree with you, the block approach seems cleaner to me.
Environments like definition or quotes appear on beamer slides as
blocks, so I think your proposal fits in better logically compared to
using headlines.

There is an added bonus to this, now headlines could be used properly to
do what it is meant to do, sectioning. Something like this would be very
nice:

#+begin_src org

 #+BEAMER_FRAME_LEVEL: 3

 * Top level section 1
 ** sub-section 1
 *** frame 1
 some intro text

 #+ATTR_BEAMER: :title "Definition"
 #+BEGIN_BLOCK
 A *set* consists of elements.
 #+END_BLOCK

 some concluding text

 ** sub-section 2
 *** another frame

 * Top level section 2
 ** sub-section
 *** some frame

#+end_src org

With this syntax it would be very easy to write both really long (40-50
frames) as well as quick and short presentations.

However this breaks backwards compatibility for existing org documents.
As a very frequent beamer export user I would be willing to break
backwards compatibility for cleaner structuring in the future. If
backwards compatibility is too precious, one could move org-beamer to
contrib and rename it org-beamer-lagacy.

Another comment/request I have is better support for overlays. It seems
to me with the block approach overlaying for blocks could be supported
with block header arguments (like babel). I'm not sure though how one
could have overlays in lists though. Maybe the [@n] syntax for ordered
lists could be exploited to support overlays with list (although I admit
it feels like a big hack)?

Hopefully these comments are helpful.

PS: I can't wait to test the new beamer exporter. :)

--
Suvayu

Open source is the future. It sets us free.

Re: [dev] About a beamer back-end

[Avdi Grimm]

[-- Attachment #1: Type: text/plain, Size: 708 bytes --]

On Fri, Jun 15, 2012 at 12:41 PM, suvayu ali <fatkasuvayu+linux@gmail.com>
 wrote:

> With this syntax it would be very easy to write both really long (40-50
> frames) as well as quick and short presentations.
>

I've only been using Org and Beamer for a little while, but if I understand
it correctly this sounds preferable.

I haven't memorized my Beamer syntax yet, but something basic that I do a
lot and I've found to be awkward in Org-Beamer is having a series of slides
where the main title stays the same but with different content for each.
I'd like to be able to write that as a section and a series of subsections.

Then again, perhaps this is already possible and I just don't know how.

--
Avdi

[-- Attachment #2: Type: text/html, Size: 1266 bytes --]

Re: [dev] About a beamer back-end

[Eric S Fraga]

Avdi Grimm <groups@inbox.avdi.org> writes:

> On Fri, Jun 15, 2012 at 12:41 PM, suvayu ali <fatkasuvayu+linux@gmail.com>
>  wrote:
>
>> With this syntax it would be very easy to write both really long (40-50
>> frames) as well as quick and short presentations.
>>
>
> I've only been using Org and Beamer for a little while, but if I understand
> it correctly this sounds preferable.

Well, I will have to chime in with a contrary view.  I like using
headlines to define blocks, and I use blocks on almost every frame.  I
have the following reasons for preferring a headline approach:

- the proposed approach does not easily (at all?) cater for blocks
  within blocks

- ease of hiding of content: org for me is still primarily an outliner!

- being able to re-arrange content in a frame quickly (M-<up>, etc.)

- within frames, there is no other use for lower level headlines.  Using
  these for blocks seems appropriate.  What else could they be used for?

Obviously, I would adapt to whatever is provided.

Thanks in advance in any case!  I look forward to beamer support in the
new exporter.
-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.1.50.1 and Org release_7.8.11-69-ga2fd96

Re: [dev] About a beamer back-end

[suvayu ali]

Hi Eric,

On Mon, Jun 18, 2012 at 9:50 AM, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:
> Avdi Grimm <groups@inbox.avdi.org> writes:
>
>> On Fri, Jun 15, 2012 at 12:41 PM, suvayu ali <fatkasuvayu+linux@gmail.com>
>>  wrote:
>>
>>> With this syntax it would be very easy to write both really long (40-50
>>> frames) as well as quick and short presentations.
>>>
>>
>> I've only been using Org and Beamer for a little while, but if I understand
>> it correctly this sounds preferable.
>
> Well, I will have to chime in with a contrary view.  I like using
> headlines to define blocks, and I use blocks on almost every frame.  I
> have the following reasons for preferring a headline approach:
>
> - the proposed approach does not easily (at all?) cater for blocks
>  within blocks
>
> - ease of hiding of content: org for me is still primarily an outliner!
>
> - being able to re-arrange content in a frame quickly (M-<up>, etc.)
>
> - within frames, there is no other use for lower level headlines.  Using
>  these for blocks seems appropriate.  What else could they be used for?
>

Those are very strong points. I didn't think this way when I gave my
comments.

> Obviously, I would adapt to whatever is provided.
>

Same goes for me here. :)

-- 
Suvayu

Open source is the future. It sets us free.

Re: [dev] About a beamer back-end

[Nicolas Goaziou]

Hello,

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> Well, I will have to chime in with a contrary view.  I like using
> headlines to define blocks, and I use blocks on almost every frame.  I
> have the following reasons for preferring a headline approach:
>
> - the proposed approach does not easily (at all?) cater for blocks
>   within blocks

I may be missing your point, but you can have nested blocks.  What would
be more difficult to achieve with blocks?

> - ease of hiding of content: org for me is still primarily an
>   outliner!

You can hide blocks too.

> - being able to re-arrange content in a frame quickly (M-<up>, etc.)

See `org-element-drag-backward' and `org-element-drag-forward'.

> - within frames, there is no other use for lower level headlines.  Using
>   these for blocks seems appropriate.  What else could they be used
>   for?

Good question.

One idea would be to use them as outline tools that would have no impact
on export (they would help hiding frame contents in the buffer but would
be ignored in produced LaTeX code).


Obviously, both approaches (blocks or headlines) have drawbacks.  I'm
still unsure about which one would be the quickest/cleanest/most useful.


Regards,

-- 
Nicolas Goaziou

Re: [dev] About a beamer back-end

[Eric S Fraga]

[-- Attachment #1: Type: text/plain, Size: 2199 bytes --]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>
>> Well, I will have to chime in with a contrary view.  I like using
>> headlines to define blocks, and I use blocks on almost every frame.  I
>> have the following reasons for preferring a headline approach:
>>
>> - the proposed approach does not easily (at all?) cater for blocks
>>   within blocks
>
> I may be missing your point, but you can have nested blocks.  What would
> be more difficult to achieve with blocks?

Sorry!  I missed the begin...end structure for the blocks you were
proposing.  Indeed, I see no reason that your proposal does not support
a recursive nesting of blocks.

>> - ease of hiding of content: org for me is still primarily an
>>   outliner!
>
> You can hide blocks too.

but the difference is that the hidden block doesn't tell you anything
about the block itself?  that is, there is no equivalent to the text
content of a headline that is visible when the contents below the
headline are hidden.  This is possibly (?) a minor point, mind you.

>> - being able to re-arrange content in a frame quickly (M-<up>, etc.)
>
> See `org-element-drag-backward' and `org-element-drag-forward'.

Okay.  Will it be easy to bind these to M-<up> etc. to achieve
consistent behaviour?  I.e. does org-metaup know what to do with blocks?

>> - within frames, there is no other use for lower level headlines.  Using
>>   these for blocks seems appropriate.  What else could they be used
>>   for?
>
> Good question.
>
> One idea would be to use them as outline tools that would have no impact
> on export (they would help hiding frame contents in the buffer but would
> be ignored in produced LaTeX code).
>
>
> Obviously, both approaches (blocks or headlines) have drawbacks.  I'm
> still unsure about which one would be the quickest/cleanest/most useful.

Understood!  And I don't want to stand in the way of an implementation
of beamer support in the new exporter.

As a point for discussion and evaluation, attached is an example slide
(both org and pdf) demonstrating the type of thing I tend to do for some
of my beamer documents.

Also, please don't forget about columns!


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: beamerblocks.org --]
[-- Type: text/org, Size: 1953 bytes --]

#+title: Blocks in beamer via org
#+author: Eric S Fraga
#+startup: beamer
#+LaTeX_CLASS: beamer
#+LaTeX_CLASS_OPTIONS: [presentation]
#+OPTIONS:   H:5 num:t toc:nil \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:nil

#+BEAMER_FRAME_LEVEL: 2

#+startup: oddonly
#+startup: fninline
#+ BEAMER_HEADER_EXTRA: \usetheme{Madrid}\usecolortheme{default}
#+ latex_header: \usepackage[absolute,overlay]{textpos}\setlength{\TPHorizModule}{1mm}\setlength{\TPVertModule}{1mm}\newcommand{\UCL}{\begin{textblock}{14}(120.0,0.0)\pgfuseimage{ucllogo}\end{textblock}}
#+latex_header: \mode<beamer>{\usetheme{progressbar}}

#+latex_header: \usepackage{tikz}
* Test
*** Nested blocks
    :PROPERTIES:
    :BEAMER_envargs: [t]
    :END:
    Use distillation for separation of two components.
***** The problem                                     :BMCOL:B_ignoreheading:
      :PROPERTIES:
      :BEAMER_col: 0.3
      :BEAMER_env: ignoreheading
      :END:
******* Equilibrium                                            :B_definition:
        :PROPERTIES:
        :BEAMER_env: definition
        :END:
        \( \displaystyle y = \frac{\alpha x} {1 + (\alpha -1) x} \)
******* Goal                                                        :B_block:
        :PROPERTIES:
        :BEAMER_env: block
        :END:
        Minimise energy consumption
***** Distillation                                          :BMCOL:B_example:
      :PROPERTIES:
      :BEAMER_col: 0.6
      :BEAMER_env: example
      :END:
      #+begin_center
      #+attr_latex: width=0.9\textwidth
      [[file:~/s/figures/teaching/introduction/distillation-unit.pdf]]
      #+end_center

      \vfill
***** Approach                                        :BMCOL:B_ignoreheading:
      :PROPERTIES:
      :BEAMER_col: 1.0
      :BEAMER_env: ignoreheading
      :END:

      \vfill

      We will use the @McCabe-Thiele@ method for the initial design.

[-- Attachment #3: beamerblocks.pdf --]
[-- Type: application/pdf, Size: 144598 bytes --]

[-- Attachment #4: Type: text/plain, Size: 102 bytes --]


-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.1.50.1 and Org release_7.8.11-69-ga2fd96

Re: [dev] About a beamer back-end

[Greg Tucker-Kellogg]

[-- Attachment #1: Type: text/plain, Size: 2798 bytes --]

I also quite like using headlines for blocks, for many of the same reasons Eric mentioned.  In addition, I regularly use column view to set BEAMER_env, BEAMER_envargs, BEAMER_extra, etc., and column view operates on headlines.

Greg



On Jun 20, 2012, at 5:04 AM, Eric S Fraga wrote:

> Nicolas Goaziou <n.goaziou@gmail.com> writes:
> 
>> Hello,
>> 
>> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>> 
>>> Well, I will have to chime in with a contrary view.  I like using
>>> headlines to define blocks, and I use blocks on almost every frame.  I
>>> have the following reasons for preferring a headline approach:
>>> 
>>> - the proposed approach does not easily (at all?) cater for blocks
>>>  within blocks
>> 
>> I may be missing your point, but you can have nested blocks.  What would
>> be more difficult to achieve with blocks?
> 
> Sorry!  I missed the begin...end structure for the blocks you were
> proposing.  Indeed, I see no reason that your proposal does not support
> a recursive nesting of blocks.
> 
>>> - ease of hiding of content: org for me is still primarily an
>>>  outliner!
>> 
>> You can hide blocks too.
> 
> but the difference is that the hidden block doesn't tell you anything
> about the block itself?  that is, there is no equivalent to the text
> content of a headline that is visible when the contents below the
> headline are hidden.  This is possibly (?) a minor point, mind you.
> 
>>> - being able to re-arrange content in a frame quickly (M-<up>, etc.)
>> 
>> See `org-element-drag-backward' and `org-element-drag-forward'.
> 
> Okay.  Will it be easy to bind these to M-<up> etc. to achieve
> consistent behaviour?  I.e. does org-metaup know what to do with blocks?
> 
>>> - within frames, there is no other use for lower level headlines.  Using
>>>  these for blocks seems appropriate.  What else could they be used
>>>  for?
>> 
>> Good question.
>> 
>> One idea would be to use them as outline tools that would have no impact
>> on export (they would help hiding frame contents in the buffer but would
>> be ignored in produced LaTeX code).
>> 
>> 
>> Obviously, both approaches (blocks or headlines) have drawbacks.  I'm
>> still unsure about which one would be the quickest/cleanest/most useful.
> 
> Understood!  And I don't want to stand in the way of an implementation
> of beamer support in the new exporter.
> 
> As a point for discussion and evaluation, attached is an example slide
> (both org and pdf) demonstrating the type of thing I tend to do for some
> of my beamer documents.
> 
> Also, please don't forget about columns!
> 
> <beamerblocks.org><beamerblocks.pdf>
> -- 
> : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
> : in Emacs 24.1.50.1 and Org release_7.8.11-69-ga2fd96


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [dev] About a beamer back-end

[Sebastien Vauban]

Hi all,

Greg Tucker-Kellogg wrote:
> On Jun 20, 2012, at 5:04 AM, Eric S Fraga wrote:
>> Nicolas Goaziou <n.goaziou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>> Eric S Fraga <e.fraga-hclig2XLE9Zaa/9Udqfwiw@public.gmane.org> writes:
>>> 
>>>> Well, I will have to chime in with a contrary view. I like using
>>>> headlines to define blocks, and I use blocks on almost every frame. I
>>>> have the following reasons for preferring a headline approach:
>>>> 
>>>> - the proposed approach does not easily (at all?) cater for blocks
>>>>  within blocks
>>> 
>>> I may be missing your point, but you can have nested blocks. What would be
>>> more difficult to achieve with blocks?
>> 
>> Sorry! I missed the begin...end structure for the blocks you were
>> proposing. Indeed, I see no reason that your proposal does not support a
>> recursive nesting of blocks.
>> 
>>>> - ease of hiding of content: org for me is still primarily an
>>>>  outliner!
>>> 
>>> You can hide blocks too.
>> 
>> but the difference is that the hidden block doesn't tell you anything about
>> the block itself? that is, there is no equivalent to the text content of a
>> headline that is visible when the contents below the headline are hidden.
>> This is possibly (?) a minor point, mind you.
>> 
>>>> - being able to re-arrange content in a frame quickly (M-<up>, etc.)
>>> 
>>> See `org-element-drag-backward' and `org-element-drag-forward'.
>> 
>> Okay. Will it be easy to bind these to M-<up> etc. to achieve consistent
>> behaviour? I.e. does org-metaup know what to do with blocks?
>> 
>>>> - within frames, there is no other use for lower level headlines.  Using
>>>>  these for blocks seems appropriate. What else could they be used for?
>>> 
>>> Good question.
>>> 
>>> One idea would be to use them as outline tools that would have no impact
>>> on export (they would help hiding frame contents in the buffer but would
>>> be ignored in produced LaTeX code).
>>> 
>>> Obviously, both approaches (blocks or headlines) have drawbacks. I'm still
>>> unsure about which one would be the quickest/cleanest/most useful.
>> 
>> Understood! And I don't want to stand in the way of an implementation of
>> beamer support in the new exporter.
>> 
>> As a point for discussion and evaluation, attached is an example slide
>> (both org and pdf) demonstrating the type of thing I tend to do for some of
>> my beamer documents.
>> 
>> Also, please don't forget about columns!
>
> I also quite like using headlines for blocks, for many of the same reasons
> Eric mentioned. In addition, I regularly use column view to set BEAMER_env,
> BEAMER_envargs, BEAMER_extra, etc., and column view operates on headlines.

Personally, I dislike using headlines for *anything* that's in the frame. I
like the idea that headlines do show the structure of your presentation:

- (optionally) sections and subsections for the sidebar
- frame title (and subtitle)

and no more.

Up to now, even if we could use headlines for itemized points, I preferred
using proper Org itemized list, and keep the whole structured that way.

I would add that headlines are inherently outline-oriented, while here we
speak about block or column contents which are inherently block-oriented
(maybe not really for the column contents, though).

I've always have had difficulties with the way to represent example blocks,
for example, *in* the flow of a normal slide...

But this whole thing is just personal taste. I'm not coming with any solution,
however!

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [dev] About a beamer back-end

[Eric S Fraga]

Sebastien Vauban <wxhgmqzgwmuf@spammotel.com> writes:

[...]

> Personally, I dislike using headlines for *anything* that's in the frame. I
> like the idea that headlines do show the structure of your presentation:
>
> - (optionally) sections and subsections for the sidebar
> - frame title (and subtitle)
>
> and no more.

This is interesting because, for me, the blocks within a frame are very
much part of the structure of the presentation.  I often start writing a
presentation with the outline consisting of sections, frame titles and
block titles.

> I would add that headlines are inherently outline-oriented, while here we
> speak about block or column contents which are inherently block-oriented
> (maybe not really for the column contents, though).

But for me, block and column headings are part of the outline.

> But this whole thing is just personal taste. I'm not coming with any solution,
> however!

Yes, it probably all does come down to personal taste and, as I have
said in an earlier message, whatever Nicolas ends up implementing will
be fine with me.
-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.1.50.1 and Org release_7.8.11-69-ga2fd96

Re: [dev] About a beamer back-end

[Nicolas Goaziou]

Hello,

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

>> See `org-element-drag-backward' and `org-element-drag-forward'.
>
> Okay.  Will it be easy to bind these to M-<up> etc. to achieve
> consistent behaviour?  I.e. does org-metaup know what to do with
> blocks?

I hope that, one day, they will replace current `org-metaup' and
`org-metadown'.

If you want to try them out (there has been no serious debugging for
them), you can

  (defalias 'org-metaup 'org-element-drag-backward)

`org-element-drag-backward' is a strict super-set for `org-metaup'.

> As a point for discussion and evaluation, attached is an example slide
> (both org and pdf) demonstrating the type of thing I tend to do for some
> of my beamer documents.

Thanks for this example, and for feedback from other Org users.

Although more logical, it appears that the block syntax for Beamer
wouldn't be that great.  Nested blocks are hard to parse (by a human)
due to their uniform fontification (contrary to headlines, whose
fontification change at every level).

Also, the syntax is very heavy. Not more than property drawers, but, at
least, you can hide those.

I'll keep headlines for blocks.  But I think I'll introduce a couple of
small changes.

- Sectioning and packages are extracted from `org-e-latex-classes'.
  Since calling Beamer back-end is explicit, it can be applied on any
  tex file, not only when that file starts with
  "\documentclass{beamer}".  Additionally, an equivalent to
  `org-beamer-use-parts' is unnecessary.

- An headline at `org-e-beamer-frame-level' level becomes a frame,
  unless it has the "noframe" tag.  In that case, its contents are
  inserted between surrounding frames.

- Any headline above that level has a block type (depending on the
  BEAMER_env property).  Without that property, the headline is still
  a block ("\begin{block}{title}...\end{block}").

- Since above some level, everything is a block, there is no "low level
  headline" anymore.  Thus, the H:num OPTION item sets
  `org-e-beamer-frame-level'.  There's no use for BEAMER_FRAME_LEVEL
  keyword.  It also means you can't make lists out of headlines.

- An headline below `org-e-beamer-frame-level' with an "appendix" tag
  becomes an appendix part.

- An headline with a "note" tag becomes a note between frames if at
  `org-e-beamer-frame-level', within current frame otherwise.

- There is no separate syntax for \alert{} command: it is the default
  output for bold objects (i.e. *text* becomes \alert{text}).

- Obviously, all special tags specified in this list are customizable.


Unfortunately I cannot get rid of "normal" environment property.  There
is also some work to do on overlays and, perhaps, links.  But let's
start with headlines first.


Regards,

-- 
Nicolas Goaziou

Re: [dev] About a beamer back-end

[Sebastien Vauban]

Hi Nicolas,

First, a big thank you for your work on this as well...

Here, inline, a couple of quick remarks...

Nicolas Goaziou wrote:
> Eric S Fraga <e.fraga-hclig2XLE9Zaa/9Udqfwiw@public.gmane.org> writes:
>
>>> See `org-element-drag-backward' and `org-element-drag-forward'.
>>
>> Okay.  Will it be easy to bind these to M-<up> etc. to achieve
>> consistent behaviour?  I.e. does org-metaup know what to do with
>> blocks?
>
> I hope that, one day, they will replace current `org-metaup' and
> `org-metadown'.
>
> If you want to try them out (there has been no serious debugging for
> them), you can
>
>   (defalias 'org-metaup 'org-element-drag-backward)
>
> `org-element-drag-backward' is a strict super-set for `org-metaup'.
>
>> As a point for discussion and evaluation, attached is an example slide
>> (both org and pdf) demonstrating the type of thing I tend to do for some
>> of my beamer documents.
>
> Thanks for this example, and for feedback from other Org users.
>
> Although more logical, it appears that the block syntax for Beamer
> wouldn't be that great.  Nested blocks are hard to parse (by a human)
> due to their uniform fontification (contrary to headlines, whose
> fontification change at every level).
>
> Also, the syntax is very heavy. Not more than property drawers, but, at
> least, you can hide those.
>
> I'll keep headlines for blocks.  But I think I'll introduce a couple of
> small changes.

OK!

> - Sectioning and packages are extracted from `org-e-latex-classes'.
>   Since calling Beamer back-end is explicit, it can be applied on any
>   tex file, not only when that file starts with
>   "\documentclass{beamer}".  Additionally, an equivalent to
>   `org-beamer-use-parts' is unnecessary.

I did not understand that one.

> - An headline at `org-e-beamer-frame-level' level becomes a frame,
>   unless it has the "noframe" tag.  In that case, its contents are
>   inserted between surrounding frames.

I never needed that -- yet --, but this is surely a great addition.

I'm wondering, though, how you support the special case of "beamer frame
level" set to 0, where we need to add the tag "B_frame" (in fact, the
property) to show where the frame really begins.

> - Any headline above that level has a block type (depending on the
>   BEAMER_env property).  Without that property, the headline is still
>   a block ("\begin{block}{title}...\end{block}").
>
> - Since above some level, everything is a block, there is no "low level
>   headline" anymore.  Thus, the H:num OPTION item sets
>   `org-e-beamer-frame-level'.  There's no use for BEAMER_FRAME_LEVEL
>   keyword.  It also means you can't make lists out of headlines.
>
> - An headline below `org-e-beamer-frame-level' with an "appendix" tag
>   becomes an appendix part.

Nice.

> - An headline with a "note" tag becomes a note between frames if at
>   `org-e-beamer-frame-level', within current frame otherwise.

Not used yet (in pure Beamer neither), but that's the following step on my
todo list...

> - There is no separate syntax for \alert{} command: it is the default
>   output for bold objects (i.e. *text* becomes \alert{text}).

I liked the fact we had 2 types of highlighting (bold, in black, and alert, in
red, in my case).

I would say that, as Beamer has those 2 different highlightings, we should be
able to still support both. Is this a problem?[1]

> - Obviously, all special tags specified in this list are customizable.
>
> Unfortunately I cannot get rid of "normal" environment property.  There
> is also some work to do on overlays and, perhaps, links.  But let's
> start with headlines first.

Fantastic work! Thanks a lot.

Best regards,
  Seb

[1] I've even done the opposite: I now have an `alert' macro as well in my
normal documents.

-- 
Sebastien Vauban

Re: [dev] About a beamer back-end

[Nicolas Goaziou]

Hello,

"Sebastien Vauban"
<wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:

>> - Sectioning and packages are extracted from `org-e-latex-classes'.
>>   Since calling Beamer back-end is explicit, it can be applied on any
>>   tex file, not only when that file starts with
>>   "\documentclass{beamer}".  Additionally, an equivalent to
>>   `org-beamer-use-parts' is unnecessary.
>
> I did not understand that one.

At the moment, beamer exporter is hooked into regular latex exporter
when latex class is "beamer".  This restriction is unnecessary when you
consider beamer as an independent back-end (i.e. you can call beamer
export even on your "article" setup).

> I'm wondering, though, how you support the special case of "beamer frame
> level" set to 0, where we need to add the tag "B_frame" (in fact, the
> property) to show where the frame really begins.

Would you mind providing an example for that? I am not aware of that
special case.

> I liked the fact we had 2 types of highlighting (bold, in black, and
> alert, in red, in my case).
>
> I would say that, as Beamer has those 2 different highlightings, we should be
> able to still support both. Is this a problem?

Not really a problem, but Org limits text markup to six elements.  You
can easily choose to use another one for bold (i.e. with filters),
though.


Regards,

-- 
Nicolas Goaziou

Re: **: Re: [dev] About a beamer back-end

[Sebastien Vauban]

Hi Nicolas,

> "Sebastien Vauban" writes:
>
>>> - Sectioning and packages are extracted from `org-e-latex-classes'.
>>>   Since calling Beamer back-end is explicit, it can be applied on any
>>>   tex file, not only when that file starts with
>>>   "\documentclass{beamer}".  Additionally, an equivalent to
>>>   `org-beamer-use-parts' is unnecessary.
>>
>> I did not understand that one.
>
> At the moment, beamer exporter is hooked into regular latex exporter
> when latex class is "beamer".  This restriction is unnecessary when you
> consider beamer as an independent back-end (i.e. you can call beamer
> export even on your "article" setup).

Cool...

>> I'm wondering, though, how you support the special case of "beamer frame
>> level" set to 0, where we need to add the tag "B_frame" (in fact, the
>> property) to show where the frame really begins.
>
> Would you mind providing an example for that? I am not aware of that
> special case.

For sure, I'm willing to do so. Here an ECM of that feature:

--8<---------------cut here---------------start------------->8---
#+TITLE:     "Free" beamer frame level
#+OPTIONS:   H:3 num:t toc:t

#+startup: beamer
#+LaTeX_CLASS: beamer
#+LaTeX_CLASS_OPTIONS: [presentation,t]
#+BEAMER_HEADER_EXTRA: \usetheme{PaloAlto}\usecolortheme{default}
#+BEAMER_FRAME_LEVEL: 0

* Introduction

** Slide 1                                                           :B_frame:
   :PROPERTIES:
   :BEAMER_env: frame
   :END:

- =BEAMER_FRAME_LEVEL: 0= gives you some flexibility in deciding what is and
  isn't a frame.

- For example, this frame is directly located under the section
  "Introduction".

* Analysis

** Client

*** Slide 2                                                          :B_frame:
    :PROPERTIES:
    :BEAMER_env: frame
    :END:

- This frame is located under the section "Analysis", subsection "Client".

*** Slide 3                                                          :B_frame:
    :PROPERTIES:
    :BEAMER_env: frame
    :END:

- You explicitly have to say which headlines are a frame by setting the
  =BEAMER_env: frame= property.

** Supplier

*** Slide 4                                                          :B_frame:
    :PROPERTIES:
    :BEAMER_env: frame
    :END:

- This becomes visible through the =B_frame= tag (visual aid only).

* Conclusion

** Slide 5                                                           :B_frame:
   :PROPERTIES:
   :BEAMER_env: frame
   :END:

- This frame is directly located under the section "Conclusion".

- No need to create a (stupidly) redundant subsection called "Conclusion"...
--8<---------------cut here---------------end--------------->8---

>> I liked the fact we had 2 types of highlighting (bold, in black, and
>> alert, in red, in my case).
>>
>> I would say that, as Beamer has those 2 different highlightings, we should be
>> able to still support both. Is this a problem?
>
> Not really a problem, but Org limits text markup to six elements.  You
> can easily choose to use another one for bold (i.e. with filters),
> though.

Sorry to insist, but I don't think it's a good idea to suppress the
distinction between alert (generally mapped to @ in private Org
configurations) and bold (*).

If I follow your advice, to get back the bold, I would have to override
another symbol, like + for example.

Not mentioning the fact it won't be standard (if I ever distribute my Org
file), but I can't export my slides once to Beamer PDF, once to a standard
document PDF without seeing big differences in the interpretation of the
symbols.

While, on the contrary, if we have an apart symbol for alert (apart from bold,
as foreseen in Beamer), and if we include such a line for the standard PDF
export:

  \providecommand{\alert}[1]{\textbf{#1}}

or, better

  \providecommand{\alert}[1]{{\textcolor{red}{\bfseries{#1}}}}

we win on both sides (we can export to both Beamer and standard doc with both
bold and alert differentiated), don't we?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: **: Re: [dev] About a beamer back-end

[Andreas Leha]

Hi,

[...]

>>> I'm wondering, though, how you support the special case of "beamer frame
>>> level" set to 0, where we need to add the tag "B_frame" (in fact, the
>>> property) to show where the frame really begins.

thanks for that tip!  This, I didn't know, but I'll use as standard now.

I never understood why there is actually the need for
the beamer_frame_level, as there is the B_frame anyway.  The
beamer_frame_level becomes annoying frequently, when there are sections
with sub-sections and sections without.

[...]

Regards,
Andreas

Re: [dev] About a beamer back-end

[Rasmus]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> - There is no separate syntax for \alert{} command: it is the default
>   output for bold objects (i.e. *text* becomes \alert{text}).

Would bold then be archived with some other markup?  Or would it just
not be possible to get bold text (without defaulting to \bold{·})?

The noframe tag sounds good.

Perhaps a pause tag would also be nice. 

–Rasmus
-- 
C is for Cookie

Re: [dev] About a beamer back-end

[Nicolas Goaziou]

Hello,

Rasmus <rasmus@gmx.us> writes:

>> - There is no separate syntax for \alert{} command: it is the default
>>   output for bold objects (i.e. *text* becomes \alert{text}).
>
> Would bold then be archived with some other markup?  Or would it just
> not be possible to get bold text (without defaulting to \bold{·})?

You have six different markups to play with: * _ + / = ~.  You can
associate bold to any one.

By default, I think alert is sufficiently close to bold so it can
replace it. Any other choice would be surprising.

> The noframe tag sounds good.

Do you have any example of the use you have in mind?  I don't know what
kind of contents one would like add between frames (excepted notes).

> Perhaps a pause tag would also be nice.

Yes, that's an idea to keep for overlays.


Regards,

-- 
Nicolas Goaziou

Re: [dev] About a beamer back-end

[Rasmus]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

>> The noframe tag sounds good.
> Do you have any example of the use you have in mind?  I don't know
> what
> kind of contents one would like add between frames (excepted notes).

 - If you are to repeat frames
   - Imagine a complicated tikz picture which you don't want to render
     twice.
 - If you use the source for an article (beamer-article), and some
   content is only meant for the article version and not indented for
   slides. 

>> Perhaps a pause tag would also be nice.
> Yes, that's an idea to keep for overlays.

–Rasmus

-- 
May the Force be with you

Re: [dev] About a beamer back-end

[suvayu ali]

Hi Nicolas,

On Thu, Jun 21, 2012 at 4:37 PM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
>
> If you want to try them out (there has been no serious debugging for
> them), you can
>
>  (defalias 'org-metaup 'org-element-drag-backward)
>
> `org-element-drag-backward' is a strict super-set for `org-metaup'.
>

I will try this out today.

> I'll keep headlines for blocks.  But I think I'll introduce a couple of
> small changes.
>
> - Sectioning and packages are extracted from `org-e-latex-classes'.
>  Since calling Beamer back-end is explicit, it can be applied on any
>  tex file, not only when that file starts with
>  "\documentclass{beamer}".  Additionally, an equivalent to
>  `org-beamer-use-parts' is unnecessary.
>

This would be a welcome addition in line with the org philosophy of
org documents being backend agnostic.

> - An headline at `org-e-beamer-frame-level' level becomes a frame,
>  unless it has the "noframe" tag.  In that case, its contents are
>  inserted between surrounding frames.
>

In one of your follow-up replies you mention you are not sure what could
be the use case. The beamer package has the option handout, that allows
one to produce handouts for your slides with text in between frames
included in the final pdf. This addition would make that process as
simple as adding the handout option to beamer and recompiling the latex
source!

> - Any headline above that level has a block type (depending on the
>  BEAMER_env property).  Without that property, the headline is still
>  a block ("\begin{block}{title}...\end{block}").
>

This is also a very nice addition.

> - Since above some level, everything is a block, there is no "low level
>  headline" anymore.  Thus, the H:num OPTION item sets
>  `org-e-beamer-frame-level'.  There's no use for BEAMER_FRAME_LEVEL
>  keyword.  It also means you can't make lists out of headlines.
>

This will again cleanup the syntax and make it more uniform across
backends. :)

> - An headline below `org-e-beamer-frame-level' with an "appendix" tag
>  becomes an appendix part.
>

I would appreciate this feature a lot!

> - An headline with a "note" tag becomes a note between frames if at
>  `org-e-beamer-frame-level', within current frame otherwise.
>
> - There is no separate syntax for \alert{} command: it is the default
>  output for bold objects (i.e. *text* becomes \alert{text}).
>

I am a little apprehensive about this. Bold is something I use (and see
others use) frequently in presentations. I would suggest changing the
choice to something that is less used in presentations. The `_' markup
could be a good candidate or one of the two `=' or `~' could be used
(since they render to something very similar in the pdf). But this is
not an important point; as long as this is configurable, I'm happy. :)

> - Obviously, all special tags specified in this list are customizable.
>

A huge thank you for all the wonderful and hard work you have put in.

:)

-- 
Suvayu

Open source is the future. It sets us free.

Re: [dev] About a beamer back-end

[Eric S Fraga]

Nicolas,

> I'll keep headlines for blocks.  But I think I'll introduce a couple of
> small changes.

I really like all the changes you propose.  The result would appear to
be a clean design.  I particularly like the defaulting of headlines to
blocks.

Unlike others, I am not bothered about *alert* taking the place of
*bold* as I never mix the two and, in fact, have alert mapped to bold
when using article instead of beamer class.

Thanks,
eric

-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.1.50.1 and Org release_7.8.11-69-ga2fd96

Re: [dev] About a beamer back-end

[Daniel Bausch]

Hi Nicolas,

first of all, I think the block idea is a good one, as long a notes will
remain headlines.  Nevertheless I often had the problem in my documents,
that I wanted to insert code between frames.  It would be great, if you
could provide a clean solution for such things, too.  (ignoreheading
does not work in all cases)  A special headline class or tag that does
not generate a frame but can contain LaTeX code that is inserted instead
of a frame would be enough.  Inserting a great number of "newcommand"
calls before the first frame would be another use of such a thing, as
the alternative, multiple "#+LaTeX_HEADER" statements, is very ugly and
even sometimes fails because of parser problems.

Then I had another problem, for which I was forced to patch the org-mode
code: My university requires me to use a corporate design for my slides.
 This design is implemented as a document class, so instead of
\documentclass{beamer} I need to use a different class name.  However,
Org Beamer only works correctly, if the documentclass is "beamer".
(#+STARTUP: beamer is NOT enough)  Therefore, I needed to change the
hardcoded string in the source code (and now can only output documents
with the corporate style).  It would be very nice, if you could find a
solution that works without a hardcoded string at all.  Maybe rely on
"#+STARTUP: beamer" or something else.  (The function I needed to modify
is org-beamer-after-initial-vars)

Kind regards,
Daniel

-- 
Daniel Bausch
Wissenschaftlicher Mitarbeiter
Technische Universität Darmstadt
Fachbereich Informatik
Fachgebiet Datenbanken und Verteilte Systeme

Hochschulstraße 10
64289 Darmstadt
Germany

Tel.: +49 6151 16 6706
Fax:  +49 6151 16 6229

Re: [dev] About a beamer back-end

[Rasmus]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> As I announced in another thread, I'm starting a Beamer back-end for
> the new export engine.

This is indeed good news. 

Here are some concerns that I would like to address compared to the
current exporter.

 - Operating with pauses are overly hard.  One can specify overlays in
   properties, but <n> is just not very convenient, as I may have to
   introduce a new number j<n.  I prefer the pause, but it does not feel
   'natural' in the current org-beamer (IMO).

 - A lot of beamer features rely on being typed in-between frames.
   Currently, one needs non-orgish hacks to archive this (at least the
   last time I investigated the issue).
   - E.g. stuff for article mode, notes etc.

 - I kind of like the block approach, but mainly because it's fast due
   to org-beamer-select-environment.  I would be open to changes, as
   long as it remains quick.  Eric's concern on moving stuff quickly is
   valid, though.
   - My main problem with blogs is that it forces me to have everything
     on slides, and I don't always want that.

 - In the current implementation of org-beamer it's hard for me to fully
   utilize the beamer-article mode, i.e. typing the presentation as an
   article.  Perhaps the issue is solvable by using multiple files and
   including them into each other;  or perhaps it is simply asking too
   much of Org.

Thanks for putting effort into this!

-Ramsus

-- 
May the Force be with you

Re: [dev] About a beamer back-end

[Sebastien Vauban]

Hello Rasmus,

Rasmus wrote:
>  - Operating with pauses are overly hard.  One can specify overlays in
>    properties, but <n> is just not very convenient, as I may have to
>    introduce a new number j<n.  I prefer the pause, but it does not feel
>    'natural' in the current org-beamer (IMO).

I certainly will put my grain of salt later on, but I wanted to quickly react
on that point, already mentionned in the thread.

IIUC, you seem to say it's difficult to use the overlay notation, but you can
use it very easily that way:

--8<---------------cut here---------------start------------->8---
** Overlay effects \\ Keep the suspense!

*** Time bomb                                                        :B_block:
    :PROPERTIES:
    :BEAMER_env: block
    :END:

1. <2-> Two more to go
2. <3-> One more to go
3. <4-> Last chance...
4. <5-> BOOM!
--8<---------------cut here---------------end--------------->8---

The same applies for itemized lists.

How would you wanna see it in a more simple fashion?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [dev] About a beamer back-end

[Rasmus]

"Sebastien Vauban"
> IIUC, you seem to say it's difficult to use the overlay notation, but
> you can
> use it very easily that way:
> ** Overlay effects \\ Keep the suspense!
>
> *** Time bomb                                                        :B_block:
>     :PROPERTIES:
>     :BEAMER_env: block
>     :END:
>
> 1. <2-> Two more to go
> 2. <3-> One more to go
> 3. <4-> Last chance...
> 4. <5-> BOOM!
>
> The same applies for itemized lists.

If I want to do piece-wise I can even implement it with a single line in
the header.  (I usually don't want that, though).

Your way is tedious unless you are very certain about your structure.
Say I want a point in between:

> 1. <2-> Two more to go
> 2. <3-> One more to go

I would have to renumber stuff throughout the reminder of the slide.
Personally, I find that I often do, but perhaps this is a flaw in my
organization skills?


I would rather use the IMO more stable \pause command, but this is still
not elegant.  What I ask for is a more general approach, which is
perhaps not specific to beamer/does not rely on LaTeX commands.

Consider an example with a block

#+begin_src org
** Beamer title     :B_frame:
   :PROPERTIES:
   :BEAMER_env: frame
   :END:

 - points leading up to example
 - I want a pause before presenting the example

## I could put in a pause here, 
## but it belongs to the example.
## Logically, it thus does not belong here

*** pause	:B_ignoreheading:
    :PROPERTIES:
    :BEAMER_env: ignoreheading
    :END:
    \pause
## I have to impose a pause in a separate block.
## But this is an annoying hack.

*** Letting variables take on value.    :B_example:   
    :PROPERTIES:
    :BEAMER_env: example
    :END:
## a \pause is no good here, as the title is not hidden

    Let $x = y$ and $y=1$.  Then $x=1$.

#+end_src

It would be nicer to have a pause tag/property, say.  It would also be
more org-ish, and could work across exporters.  Pause of the <n> syntax
is not that pretty, and is beamer-specific.

Perhaps in general it would be more beneficial to think of a
org-e-slides, and a specialized org-e-slides-beamer?  (The main reason
for using Beamer to me is math and note support).

–Rasmus

-- 
When in doubt, do it!

Re: [dev] About a beamer back-end

[Andreas Leha]

Hi Nicolas,

> As I announced in another thread, I'm starting a Beamer back-end for the
> new export engine.  Though, before I start hacking, I have a question
> about environments.

Will this new backend support presentations in subtrees?  I think, what
I want is not possible with the current one. 

As an example, consider files structured like this:

#+begin_src org
* Presentations
** Workshop 2013
** Conference 2013

* Paper for journal X

* Actual work on Project with all the code, etc

#+end_src

Regards,
Andreas

Re: [dev] About a beamer back-end

[suvayu ali]

Hi Andreas,

On Thu, Jun 28, 2012 at 12:40 PM, Andreas Leha
<andreas.leha@med.uni-goettingen.de> wrote:
> Will this new backend support presentations in subtrees?  I think, what
> I want is not possible with the current one.
>
> As an example, consider files structured like this:
>
> #+begin_src org
> * Presentations
> ** Workshop 2013
> ** Conference 2013
>
> * Paper for journal X
>
> * Actual work on Project with all the code, etc
>
> #+end_src

I do this all the time with the current exporter. You need to insert the
beamer options in subtree properties. You can use
`org-insert-beamer-options-template' to insert the options conveniently.
After this you can export the subtree to get your presentation.

-- 
Suvayu

Open source is the future. It sets us free.

Re: [dev] About a beamer back-end

[Andreas Leha]

Hi suvayu ali,

> Hi Andreas,
>
> On Thu, Jun 28, 2012 at 12:40 PM, Andreas Leha
> <andreas.leha@med.uni-goettingen.de> wrote:
>> Will this new backend support presentations in subtrees?  I think, what
>> I want is not possible with the current one.
>>
>> As an example, consider files structured like this:
>>
>> #+begin_src org
>> * Presentations
>> ** Workshop 2013
>> ** Conference 2013
>>
>> * Paper for journal X
>>
>> * Actual work on Project with all the code, etc
>>
>> #+end_src
>
> I do this all the time with the current exporter. You need to insert the
> beamer options in subtree properties. You can use
> `org-insert-beamer-options-template' to insert the options conveniently.
> After this you can export the subtree to get your presentation.

Wow great!  I did not know about this.  Thanks a lot!

Cheers,
Andreas