Re: [O] [beamer] When are :BEAMER_envargs: used or ignored?

[Eric Fraga]

James Harkins <address@hidden> writes:

> At Wed, 25 Apr 2012 14:11:51 +0930,
> Eric Fraga wrote:
>> > It kind of strikes me like an epic hack: you have to name the headline
>> > after the Beamer color ID, instead of naming the headline after the
>
>> > content... not very /org/anized.
>> 
>> Well, the problem is that a beamercolorbox is *not* a block and does not
>> expect a title parameter.  It actually expects only a colour (well, a
>> beamer colour structure, to be precise, such as the one you have
>> defined).  What is /org/ expected to do with the entry you specify?
>
> If the subtree is folded, then the headline shows the color descriptor
> but nothing about the content of the subtree! That's some distance
> away from "an outline works like your brain."

Yes.  You could, of course, turn my suggestion inside out: have the
block first and then the coloured box as a subheading...  then the main
heading would at least give you an indication of what follows.

> It's not that I can't get the right output. It *is* a pretty stark
> inconsistency against org-mode's governing principle. Here, formatting
> information that is irrelevant to content is promoted to be the *most
> important thing* (the headline) of that subtree. What I need to see,
> in order to understand the structure of the content at a glance --
> this IMO is org-mode's genius -- is hidden if the subtree is
> folded. Hm?
>
> It strikes me as flawed design.

Well, it's a compromise, I would suggest.  most compromises can indeed
be considered flawed design from an aesthetic point of view.  org is
based on outlines, not on containers.  Latex is based on containers
(mostly).  This basic inconsistency comes up all the time on this list
(e.g. a lower level entry can only be ended by starting a new headline
at the same or higher level).

>> > Worth a bug report or feature request?
>> 
>> It is not a bug, IMO.
>
> Okay, it's not a bug in the strict sense of a feature that doesn't behave as 
> designed. I would say it's a address@hidden ugly design.

Fine.  That's one view.  I would suggest that maybe you could suggest a
better design, remembering, of course, that the basis of org is an
outliner...?

> It's also a matter of incomplete documentation. The syntax is

Indeed.  And I am partly to blame for this.  I do have a number of
outstanding TODO items with respect to the documentation of beamer
support in org.  But I also do have a real job which, unfortunately,
seems to take increasingly more hours every day...

> /perhaps/ straightforward, *after* spending some time wondering why it
> didn't work to put the color into an environment argument (as one
> might reasonably guess), and then spending more time constructing some
> tests and looking at the *.tex output to find out which bit of org
> text gets put where in the TeX code.
>
> C-c C-b lists 19 ways to tag headlines for Beamer environments. [1]

Yes, because the documentation was written to illustrate how org could
support beamer; a comprehensive document has never been written.  I
would be happy if you would consider contributing to the documentation?


-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1
: using Org-mode version 7.8.06 (release_7.8.06.181.g67694.dirty)