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 writes: > >> Hello, >> >> Eric S Fraga 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-, etc.) >> >> See `org-element-drag-backward' and `org-element-drag-forward'. > > Okay. Will it be easy to bind these to M- 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! > > > -- > : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D > : in Emacs 24.1.50.1 and Org release_7.8.11-69-ga2fd96