Re: [dev] About a beamer back-end

["Sebastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org>]

Hi Nicolas,

First, a big thank you for your work on this as well...

Here, inline, a couple of quick remarks...

Nicolas Goaziou wrote:
> Eric S Fraga <e.fraga-hclig2XLE9Zaa/9Udqfwiw@public.gmane.org> writes:
>
>>> 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?
>
> I hope that, one day, they will replace current `org-metaup' and
> `org-metadown'.
>
> If you want to try them out (there has been no serious debugging for
> them), you can
>
>   (defalias 'org-metaup 'org-element-drag-backward)
>
> `org-element-drag-backward' is a strict super-set for `org-metaup'.
>
>> 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.
>
> Thanks for this example, and for feedback from other Org users.
>
> Although more logical, it appears that the block syntax for Beamer
> wouldn't be that great.  Nested blocks are hard to parse (by a human)
> due to their uniform fontification (contrary to headlines, whose
> fontification change at every level).
>
> Also, the syntax is very heavy. Not more than property drawers, but, at
> least, you can hide those.
>
> I'll keep headlines for blocks.  But I think I'll introduce a couple of
> small changes.

OK!

> - Sectioning and packages are extracted from `org-e-latex-classes'.
>   Since calling Beamer back-end is explicit, it can be applied on any
>   tex file, not only when that file starts with
>   "\documentclass{beamer}".  Additionally, an equivalent to
>   `org-beamer-use-parts' is unnecessary.

I did not understand that one.

> - An headline at `org-e-beamer-frame-level' level becomes a frame,
>   unless it has the "noframe" tag.  In that case, its contents are
>   inserted between surrounding frames.

I never needed that -- yet --, but this is surely a great addition.

I'm wondering, though, how you support the special case of "beamer frame
level" set to 0, where we need to add the tag "B_frame" (in fact, the
property) to show where the frame really begins.

> - Any headline above that level has a block type (depending on the
>   BEAMER_env property).  Without that property, the headline is still
>   a block ("\begin{block}{title}...\end{block}").
>
> - Since above some level, everything is a block, there is no "low level
>   headline" anymore.  Thus, the H:num OPTION item sets
>   `org-e-beamer-frame-level'.  There's no use for BEAMER_FRAME_LEVEL
>   keyword.  It also means you can't make lists out of headlines.
>
> - An headline below `org-e-beamer-frame-level' with an "appendix" tag
>   becomes an appendix part.

Nice.

> - An headline with a "note" tag becomes a note between frames if at
>   `org-e-beamer-frame-level', within current frame otherwise.

Not used yet (in pure Beamer neither), but that's the following step on my
todo list...

> - There is no separate syntax for \alert{} command: it is the default
>   output for bold objects (i.e. *text* becomes \alert{text}).

I liked the fact we had 2 types of highlighting (bold, in black, and alert, in
red, in my case).

I would say that, as Beamer has those 2 different highlightings, we should be
able to still support both. Is this a problem?[1]

> - Obviously, all special tags specified in this list are customizable.
>
> Unfortunately I cannot get rid of "normal" environment property.  There
> is also some work to do on overlays and, perhaps, links.  But let's
> start with headlines first.

Fantastic work! Thanks a lot.

Best regards,
  Seb

[1] I've even done the opposite: I now have an `alert' macro as well in my
normal documents.

-- 
Sebastien Vauban