Re: Re: New beamer support

[Carsten Dominik <carsten.dominik@gmail.com>]

On Jan 7, 2010, at 7:03 PM, Darlan Cavalcante Moreira wrote:

>
> I agree that it is useful to have an easy way to specify one or more  
> options for
> every frame, but from the beamer manual I understand that these  
> options where
> created for specific cases and IMHO org shouldn't include any frame  
> option by
> default.
>
> About the fragile option, the beamer manual tells you when to use  
> it, but
> doesn't mention any drawbacks of its use. I also tried searching for  
> problems
> with the fragile option but I found nothing and therefore I do not  
> know the
> implications of enabling the fragile option in every frame. However,  
> if there is
> no drawbacks then I wonder why the beamer author didn't make it the  
> default
> behavior.

Because it is slow - each frame source code has to be written to a  
file, then read back in.

- Carsten

>
> Maybe it is better to ask in a beamer mailing list the implications  
> of setting
> this option for every frame.
>
> - Darlan Cavalcante Moreira
>
> At Thu, 07 Jan 2010 17:16:55 +0100,
> Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> wrote:
>>
>> 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.
>> Emacs-orgmode@gnu.org
>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

- Carsten