* [dev] About a beamer back-end
@ 2012-06-15 15:08 Nicolas Goaziou
2012-06-15 16:41 ` suvayu ali
` (3 more replies)
0 siblings, 4 replies; 27+ messages in thread
From: Nicolas Goaziou @ 2012-06-15 15:08 UTC (permalink / raw)
To: Org Mode List
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
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: [dev] About a beamer back-end 2012-06-15 15:08 [dev] About a beamer back-end Nicolas Goaziou @ 2012-06-15 16:41 ` suvayu ali 2012-06-15 16:47 ` Avdi Grimm 2012-06-18 6:32 ` Daniel Bausch ` (2 subsequent siblings) 3 siblings, 1 reply; 27+ messages in thread From: suvayu ali @ 2012-06-15 16:41 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Org Mode List 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [dev] About a beamer back-end 2012-06-15 16:41 ` suvayu ali @ 2012-06-15 16:47 ` Avdi Grimm 2012-06-18 7:50 ` Eric S Fraga 0 siblings, 1 reply; 27+ messages in thread From: Avdi Grimm @ 2012-06-15 16:47 UTC (permalink / raw) To: Org Mode List [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [dev] About a beamer back-end 2012-06-15 16:47 ` Avdi Grimm @ 2012-06-18 7:50 ` Eric S Fraga 2012-06-18 12:35 ` suvayu ali 2012-06-19 13:21 ` Nicolas Goaziou 0 siblings, 2 replies; 27+ messages in thread From: Eric S Fraga @ 2012-06-18 7:50 UTC (permalink / raw) To: Avdi Grimm; +Cc: Org Mode List 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [dev] About a beamer back-end 2012-06-18 7:50 ` Eric S Fraga @ 2012-06-18 12:35 ` suvayu ali 2012-06-19 13:21 ` Nicolas Goaziou 1 sibling, 0 replies; 27+ messages in thread From: suvayu ali @ 2012-06-18 12:35 UTC (permalink / raw) To: Org Mode List 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [dev] About a beamer back-end 2012-06-18 7:50 ` Eric S Fraga 2012-06-18 12:35 ` suvayu ali @ 2012-06-19 13:21 ` Nicolas Goaziou 2012-06-19 21:04 ` Eric S Fraga 1 sibling, 1 reply; 27+ messages in thread From: Nicolas Goaziou @ 2012-06-19 13:21 UTC (permalink / raw) To: Avdi Grimm; +Cc: Org Mode List 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [dev] About a beamer back-end 2012-06-19 13:21 ` Nicolas Goaziou @ 2012-06-19 21:04 ` Eric S Fraga 2012-06-20 6:23 ` Greg Tucker-Kellogg 2012-06-21 14:37 ` Nicolas Goaziou 0 siblings, 2 replies; 27+ messages in thread From: Eric S Fraga @ 2012-06-19 21:04 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Org Mode List [-- 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [dev] About a beamer back-end 2012-06-19 21:04 ` Eric S Fraga @ 2012-06-20 6:23 ` Greg Tucker-Kellogg 2012-06-20 11:55 ` Sebastien Vauban 2012-06-21 14:37 ` Nicolas Goaziou 1 sibling, 1 reply; 27+ messages in thread From: Greg Tucker-Kellogg @ 2012-06-20 6:23 UTC (permalink / raw) To: Eric S Fraga; +Cc: Org Mode List, Nicolas Goaziou [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [dev] About a beamer back-end 2012-06-20 6:23 ` Greg Tucker-Kellogg @ 2012-06-20 11:55 ` Sebastien Vauban 2012-06-20 15:20 ` Eric S Fraga 0 siblings, 1 reply; 27+ messages in thread From: Sebastien Vauban @ 2012-06-20 11:55 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [dev] About a beamer back-end 2012-06-20 11:55 ` Sebastien Vauban @ 2012-06-20 15:20 ` Eric S Fraga 0 siblings, 0 replies; 27+ messages in thread From: Eric S Fraga @ 2012-06-20 15:20 UTC (permalink / raw) To: Sebastien Vauban; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [dev] About a beamer back-end 2012-06-19 21:04 ` Eric S Fraga 2012-06-20 6:23 ` Greg Tucker-Kellogg @ 2012-06-21 14:37 ` Nicolas Goaziou 2012-06-21 14:51 ` Sebastien Vauban ` (3 more replies) 1 sibling, 4 replies; 27+ messages in thread From: Nicolas Goaziou @ 2012-06-21 14:37 UTC (permalink / raw) To: Org Mode List 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [dev] About a beamer back-end 2012-06-21 14:37 ` Nicolas Goaziou @ 2012-06-21 14:51 ` Sebastien Vauban 2012-06-21 16:03 ` Nicolas Goaziou 2012-06-21 14:55 ` Rasmus ` (2 subsequent siblings) 3 siblings, 1 reply; 27+ messages in thread From: Sebastien Vauban @ 2012-06-21 14:51 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [dev] About a beamer back-end 2012-06-21 14:51 ` Sebastien Vauban @ 2012-06-21 16:03 ` Nicolas Goaziou [not found] ` <87obocodo7.fsf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 0 siblings, 1 reply; 27+ messages in thread From: Nicolas Goaziou @ 2012-06-21 16:03 UTC (permalink / raw) To: Sebastien Vauban; +Cc: public-emacs-orgmode-mXXj517/zsQ 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <87obocodo7.fsf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: **: Re: [dev] About a beamer back-end [not found] ` <87obocodo7.fsf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> @ 2012-06-21 21:14 ` Sebastien Vauban 2012-06-25 22:39 ` Andreas Leha 0 siblings, 1 reply; 27+ messages in thread From: Sebastien Vauban @ 2012-06-21 21:14 UTC (permalink / raw) To: re.ITWSQOTHJVN9M-geNee64TY+gS+FvcfC7Uqw Cc: public-emacs-orgmode-mXXj517/zsQ-wOFGN7rlS/M9smdsby/KFg, 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: **: Re: [dev] About a beamer back-end 2012-06-21 21:14 ` **: " Sebastien Vauban @ 2012-06-25 22:39 ` Andreas Leha 0 siblings, 0 replies; 27+ messages in thread From: Andreas Leha @ 2012-06-25 22:39 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [dev] About a beamer back-end 2012-06-21 14:37 ` Nicolas Goaziou 2012-06-21 14:51 ` Sebastien Vauban @ 2012-06-21 14:55 ` Rasmus 2012-06-21 15:56 ` Nicolas Goaziou 2012-06-21 16:49 ` suvayu ali 2012-06-22 7:54 ` Eric S Fraga 3 siblings, 1 reply; 27+ messages in thread From: Rasmus @ 2012-06-21 14:55 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [dev] About a beamer back-end 2012-06-21 14:55 ` Rasmus @ 2012-06-21 15:56 ` Nicolas Goaziou 2012-06-21 16:36 ` Rasmus 0 siblings, 1 reply; 27+ messages in thread From: Nicolas Goaziou @ 2012-06-21 15:56 UTC (permalink / raw) To: Rasmus; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [dev] About a beamer back-end 2012-06-21 15:56 ` Nicolas Goaziou @ 2012-06-21 16:36 ` Rasmus 0 siblings, 0 replies; 27+ messages in thread From: Rasmus @ 2012-06-21 16:36 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [dev] About a beamer back-end 2012-06-21 14:37 ` Nicolas Goaziou 2012-06-21 14:51 ` Sebastien Vauban 2012-06-21 14:55 ` Rasmus @ 2012-06-21 16:49 ` suvayu ali 2012-06-22 7:54 ` Eric S Fraga 3 siblings, 0 replies; 27+ messages in thread From: suvayu ali @ 2012-06-21 16:49 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Org Mode List 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [dev] About a beamer back-end 2012-06-21 14:37 ` Nicolas Goaziou ` (2 preceding siblings ...) 2012-06-21 16:49 ` suvayu ali @ 2012-06-22 7:54 ` Eric S Fraga 3 siblings, 0 replies; 27+ messages in thread From: Eric S Fraga @ 2012-06-22 7:54 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Org Mode List 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [dev] About a beamer back-end 2012-06-15 15:08 [dev] About a beamer back-end Nicolas Goaziou 2012-06-15 16:41 ` suvayu ali @ 2012-06-18 6:32 ` Daniel Bausch 2012-06-18 10:17 ` Rasmus 2012-06-28 10:40 ` Andreas Leha 3 siblings, 0 replies; 27+ messages in thread From: Daniel Bausch @ 2012-06-18 6:32 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [dev] About a beamer back-end 2012-06-15 15:08 [dev] About a beamer back-end Nicolas Goaziou 2012-06-15 16:41 ` suvayu ali 2012-06-18 6:32 ` Daniel Bausch @ 2012-06-18 10:17 ` Rasmus 2012-06-18 10:35 ` Sebastien Vauban 2012-06-28 10:40 ` Andreas Leha 3 siblings, 1 reply; 27+ messages in thread From: Rasmus @ 2012-06-18 10:17 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [dev] About a beamer back-end 2012-06-18 10:17 ` Rasmus @ 2012-06-18 10:35 ` Sebastien Vauban 2012-06-18 12:00 ` Rasmus 0 siblings, 1 reply; 27+ messages in thread From: Sebastien Vauban @ 2012-06-18 10:35 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [dev] About a beamer back-end 2012-06-18 10:35 ` Sebastien Vauban @ 2012-06-18 12:00 ` Rasmus 0 siblings, 0 replies; 27+ messages in thread From: Rasmus @ 2012-06-18 12:00 UTC (permalink / raw) To: emacs-orgmode "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! ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [dev] About a beamer back-end 2012-06-15 15:08 [dev] About a beamer back-end Nicolas Goaziou ` (2 preceding siblings ...) 2012-06-18 10:17 ` Rasmus @ 2012-06-28 10:40 ` Andreas Leha 2012-06-28 10:47 ` suvayu ali 3 siblings, 1 reply; 27+ messages in thread From: Andreas Leha @ 2012-06-28 10:40 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [dev] About a beamer back-end 2012-06-28 10:40 ` Andreas Leha @ 2012-06-28 10:47 ` suvayu ali 2012-06-28 10:50 ` Andreas Leha 0 siblings, 1 reply; 27+ messages in thread From: suvayu ali @ 2012-06-28 10:47 UTC (permalink / raw) To: Andreas Leha; +Cc: emacs-orgmode 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [dev] About a beamer back-end 2012-06-28 10:47 ` suvayu ali @ 2012-06-28 10:50 ` Andreas Leha 0 siblings, 0 replies; 27+ messages in thread From: Andreas Leha @ 2012-06-28 10:50 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2012-06-28 10:52 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-06-15 15:08 [dev] About a beamer back-end Nicolas Goaziou
2012-06-15 16:41 ` suvayu ali
2012-06-15 16:47 ` Avdi Grimm
2012-06-18 7:50 ` Eric S Fraga
2012-06-18 12:35 ` suvayu ali
2012-06-19 13:21 ` Nicolas Goaziou
2012-06-19 21:04 ` Eric S Fraga
2012-06-20 6:23 ` Greg Tucker-Kellogg
2012-06-20 11:55 ` Sebastien Vauban
2012-06-20 15:20 ` Eric S Fraga
2012-06-21 14:37 ` Nicolas Goaziou
2012-06-21 14:51 ` Sebastien Vauban
2012-06-21 16:03 ` Nicolas Goaziou
[not found] ` <87obocodo7.fsf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-06-21 21:14 ` **: " Sebastien Vauban
2012-06-25 22:39 ` Andreas Leha
2012-06-21 14:55 ` Rasmus
2012-06-21 15:56 ` Nicolas Goaziou
2012-06-21 16:36 ` Rasmus
2012-06-21 16:49 ` suvayu ali
2012-06-22 7:54 ` Eric S Fraga
2012-06-18 6:32 ` Daniel Bausch
2012-06-18 10:17 ` Rasmus
2012-06-18 10:35 ` Sebastien Vauban
2012-06-18 12:00 ` Rasmus
2012-06-28 10:40 ` Andreas Leha
2012-06-28 10:47 ` suvayu ali
2012-06-28 10:50 ` Andreas Leha
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).