emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Sebastien Vauban
Subject: Re: [O] [dev] About a beamer back-end
Date: Wed, 20 Jun 2012 13:55:06 +0200
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.1 (windows-nt)

Hi all,

Greg Tucker-Kellogg wrote:
> On Jun 20, 2012, at 5:04 AM, Eric S Fraga wrote:
>> Nicolas Goaziou <address@hidden> writes:
>>> Eric S Fraga <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]