From: "Sebastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org>
To: emacs-orgmode-mXXj517/zsQ@public.gmane.org
Subject: Re: [dev] About a beamer back-end
Date: Wed, 20 Jun 2012 13:55:06 +0200 [thread overview]
Message-ID: <80oboedwpx.fsf@somewhere.org> (raw)
In-Reply-To: 662913B2-BB47-4A3A-AACD-D7FC6F59927B@gmail.com
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
next prev parent reply other threads:[~2012-06-20 11:55 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
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=80oboedwpx.fsf@somewhere.org \
--to=wxhgmqzgwmuf-genee64ty+gs+fvcfc7uqw@public.gmane.org \
--cc=emacs-orgmode-mXXj517/zsQ@public.gmane.org \
/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).