Hi Carsten and Darlan,
Carsten Dominik wrote:
On Jan 7, 2010, at 3:39 PM, Darlan Cavalcante Moreira wrote:
Carsten Dominik wrote:
On Jan 6, 2010, at 5:22 PM, Sébastien Vauban wrote:
Carsten Dominik wrote:
there is now a new option org-beamer-frame-default-options
Though, wouldn't it be better to explicitly add something like:
--8<---------------cut here---------------start-------------
>8---
#+BEAMER_FRAME_EXTRA_OPTIONS: [allowframebreaks]
--8<---------------cut here---------------end---------------
>8---
Yes, that would make sense if it is a frequently used feature.
I like to
hesitate with introducing these special customizations until I am
convinced that this is used reasonably often. Otherwise I would
have to
have 1000 of the special lines, approximately.
Question to all: How likely is the use of a default option
you'd want to
have on *every* frame?
The problem is similar to the `fragile' option. Either we can
detect the
"overflow" (and the automatically add the option only when
needed), or we
must add it everywhere in order to ensure we won't have text cut.
It's a bit different from when we directly edit beamer files. We
compile
often and we see the problem appearing.
Here, with Org, we would just work in Org only, and publish once
at the
end. A bit more easy to be aware that some text may have pass
away.
As #+BIND works, I can imagine living quite honestly the way it
currently
is, but I let the others decide upon this.
I don't think org-mode should try to detect when to use any of
the frame
options in beamer. This could get into the way more then helping,
specially
the allowframebreaks option.
I don't see what the problem could be of enabling (or having the
possibility
to enable) that option on every slide by default.
In fact, the beamer manual tells you not to use the
allowframebreaks option
except for long bibliographies (well, it also tells you not to
use long
bibliographies) and I agree with this.
Just read page 56 of the beamer manual. Makes (some) sense, yes.
In a presentation you have to choose carefully what you will put
in each
slide and always leaving this to beamer with the allowframebreaks
is not a
good approach.
Still, I don't really see which problem this would bring, even if
that's not
the purest manner of writing slides.
BTW, yes, I saw one problem. There is some orphan title on the
bottom of one
page, and the contents on the top of the next one. Maybe, though,
that can be
easily fixed by `nobreaks' macros (either manual or automatic).
In addition, I agree that when working in a presentation with
org- mode you
compile much less, but you should still compile sometimes to see
if the
slides are well designed.
That's really the point. Contents vs Presentation.
At least, my biggest problem is that I like to be warned somehow
(but how?)
that such a problem is occurring, that some slide's contents is
just too big
to stay on one page.
I would quite not like to have to scan the full presentation,
comparing the
Org source and the beamer PDF in order to see if every line is in
both. Don't
forget we can author such a presentation with multiple persons
working on the
Org source, and that (as well) it's never always right or wrong:
*changing of
theme* brings fonts differences or margins *differences that can
hide lines
that were supposed to be visible*.
I basically understand your point, but my objection is about having
constantly
to check the results for missing lines.
I don't know if Carsten has plans to implement this, but a "fast
preview"
that exports and compiles only the current slide could be useful
here.
At last, I have a small feature request that would help
organizing the
information among the slides. Right now you can use Alt+up/down
arrow to
move a list item in a heading, but org does not allow passing
beyond a
heading limit. This makes sense in a normal org file and is very
useful,
but when writing a presentation with org this restriction can get
into the
way. This is not a big deal, but maybe others are also interested
in this.
Having to spend more time to move items from one slide to the other
would make
such a feature useful for me as well, I guess.
Do you also think I should not try to add the fragile option
automatically?
Not sure if we can apply the above reasoning to that one. The
question
certainly merits to be asked, but I'm not enlightened enough to
give an
answer.
That's true that if we say: "it's up to the user" for the slide
preparation,
we can apply that to everything, or consider the automatic stuff to
be really
good.
Just don't know.
Best regards,
Seb
--
Sébastien Vauban
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
address@hidden
http://lists.gnu.org/mailman/listinfo/emacs-orgmode