From: Eric Fraga <e.fraga@ucl.ac.uk>
To: James Harkins <jamshark70@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [beamer] When are :BEAMER_envargs: used or ignored?
Date: Wed, 25 Apr 2012 22:45:29 +0930 [thread overview]
Message-ID: <877gx4kl5a.fsf@ucl.ac.uk> (raw)
In-Reply-To: <874ns89l81.wl%jamshark70@dewdrop-world.net> (James Harkins's message of "Wed, 25 Apr 2012 18:09:18 +0800")
James Harkins <jamshark70@gmail.com> 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 d@mn 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)
prev parent reply other threads:[~2012-04-25 14:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-27 7:07 [beamer] When are :BEAMER_envargs: used or ignored? James Harkins
2012-04-25 4:41 ` Eric Fraga
2012-04-25 10:09 ` James Harkins
2012-04-25 12:49 ` James Harkins
2012-04-26 8:14 ` Eric Fraga
2012-04-26 9:51 ` James Harkins
2012-04-26 11:15 ` Sebastien Vauban
2012-04-25 13:15 ` Eric Fraga [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877gx4kl5a.fsf@ucl.ac.uk \
--to=e.fraga@ucl.ac.uk \
--cc=emacs-orgmode@gnu.org \
--cc=jamshark70@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).