From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: Re: New beamer support Date: Thu, 7 Jan 2010 19:18:41 +0100 Message-ID: <3AA6BCD7-0FFD-4EEC-8889-5CB302DEC031@gmail.com> References: <871vi3bm62.fsf@mundaneum.com> <87eim3zckf.wl%ucecesf@ucl.ac.uk> <87hbqzo05z.fsf@mundaneum.com> <87iqbfcifr.fsf@mundaneum.com> <87y6kab93a.fsf@mundaneum.com> <4b45f234.8702be0a.68d2.ffffd38c@mx.google.com> <87zl4pq494.fsf@mundaneum.com> <4b4621fe.e402be0a.7dfd.ffffdb7a@mx.google.com> Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSwwg-00014r-Bx for emacs-orgmode@gnu.org; Thu, 07 Jan 2010 13:18:54 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSwwb-0000xW-8G for emacs-orgmode@gnu.org; Thu, 07 Jan 2010 13:18:53 -0500 Received: from [199.232.76.173] (port=48677 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSwwb-0000xH-1P for emacs-orgmode@gnu.org; Thu, 07 Jan 2010 13:18:49 -0500 Received: from mx20.gnu.org ([199.232.41.8]:19115) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NSwwa-0001gC-NL for emacs-orgmode@gnu.org; Thu, 07 Jan 2010 13:18:48 -0500 Received: from mail-ew0-f224.google.com ([209.85.219.224]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NSwwZ-0005W5-QA for emacs-orgmode@gnu.org; Thu, 07 Jan 2010 13:18:48 -0500 Received: by ewy24 with SMTP id 24so21888860ewy.26 for ; Thu, 07 Jan 2010 10:18:45 -0800 (PST) In-Reply-To: <4b4621fe.e402be0a.7dfd.ffffdb7a@mx.google.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Darlan Cavalcante Moreira Cc: =?ISO-8859-1?Q?S=E9bastien_Vauban?= , emacs-orgmode@gnu.org 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 =20= > options for > every frame, but from the beamer manual I understand that these =20 > options where > created for specific cases and IMHO org shouldn't include any frame =20= > option by > default. > > About the fragile option, the beamer manual tells you when to use =20 > it, but > doesn't mention any drawbacks of its use. I also tried searching for =20= > problems > with the fragile option but I found nothing and therefore I do not =20 > know the > implications of enabling the fragile option in every frame. However, =20= > if there is > no drawbacks then I wonder why the beamer author didn't make it the =20= > default > behavior. Because it is slow - each frame source code has to be written to a =20 file, then read back in. - Carsten > > Maybe it is better to ask in a beamer mailing list the implications =20= > of setting > this option for every frame. > > - Darlan Cavalcante Moreira > > At Thu, 07 Jan 2010 17:16:55 +0100, > S=E9bastien Vauban 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=E9bastien 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-------------=20 >>>>>>> >8--- >>>>>>> #+BEAMER_FRAME_EXTRA_OPTIONS: [allowframebreaks] >>>>>>> --8<---------------cut here---------------end---------------=20 >>>>>>> >8--- >>>>>> >>>>>> Yes, that would make sense if it is a frequently used feature. =20= >>>>>> I like to >>>>>> hesitate with introducing these special customizations until I am >>>>>> convinced that this is used reasonably often. Otherwise I would =20= >>>>>> have to >>>>>> have 1000 of the special lines, approximately. >>>>>> >>>>>> Question to all: How likely is the use of a default option =20 >>>>>> you'd want to >>>>>> have on *every* frame? >>>>> >>>>> The problem is similar to the `fragile' option. Either we can =20 >>>>> detect the >>>>> "overflow" (and the automatically add the option only when =20 >>>>> 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 =20= >>>>> compile >>>>> often and we see the problem appearing. >>>>> >>>>> Here, with Org, we would just work in Org only, and publish once =20= >>>>> at the >>>>> end. A bit more easy to be aware that some text may have pass =20 >>>>> away. >>>>> >>>>> As #+BIND works, I can imagine living quite honestly the way it =20= >>>>> 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 =20 >>>> the frame >>>> options in beamer. This could get into the way more then helping, =20= >>>> specially >>>> the allowframebreaks option. >> >> I don't see what the problem could be of enabling (or having the =20 >> possibility >> to enable) that option on every slide by default. >> >> >>>> In fact, the beamer manual tells you not to use the =20 >>>> allowframebreaks option >>>> except for long bibliographies (well, it also tells you not to =20 >>>> 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 =20= >>>> in each >>>> slide and always leaving this to beamer with the allowframebreaks =20= >>>> is not a >>>> good approach. >> >> Still, I don't really see which problem this would bring, even if =20 >> that's not >> the purest manner of writing slides. >> >> BTW, yes, I saw one problem. There is some orphan title on the =20 >> bottom of one >> page, and the contents on the top of the next one. Maybe, though, =20 >> that can be >> easily fixed by `nobreaks' macros (either manual or automatic). >> >> >>>> In addition, I agree that when working in a presentation with =20 >>>> org- mode you >>>> compile much less, but you should still compile sometimes to see =20= >>>> 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 =20 >> (but how?) >> that such a problem is occurring, that some slide's contents is =20 >> just too big >> to stay on one page. >> >> I would quite not like to have to scan the full presentation, =20 >> comparing the >> Org source and the beamer PDF in order to see if every line is in =20 >> both. Don't >> forget we can author such a presentation with multiple persons =20 >> working on the >> Org source, and that (as well) it's never always right or wrong: =20 >> *changing of >> theme* brings fonts differences or margins *differences that can =20 >> hide lines >> that were supposed to be visible*. >> >> I basically understand your point, but my objection is about having =20= >> constantly >> to check the results for missing lines. >> >> >>>> I don't know if Carsten has plans to implement this, but a "fast =20= >>>> preview" >>>> that exports and compiles only the current slide could be useful =20= >>>> here. >>>> >>>> At last, I have a small feature request that would help =20 >>>> organizing the >>>> information among the slides. Right now you can use Alt+up/down =20 >>>> arrow to >>>> move a list item in a heading, but org does not allow passing =20 >>>> beyond a >>>> heading limit. This makes sense in a normal org file and is very =20= >>>> useful, >>>> but when writing a presentation with org this restriction can get =20= >>>> into the >>>> way. This is not a big deal, but maybe others are also interested =20= >>>> in this. >> >> Having to spend more time to move items from one slide to the other =20= >> 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 =20 >>> automatically? >> >> Not sure if we can apply the above reasoning to that one. The =20 >> question >> certainly merits to be asked, but I'm not enlightened enough to =20 >> give an >> answer. >> >> That's true that if we say: "it's up to the user" for the slide =20 >> preparation, >> we can apply that to everything, or consider the automatic stuff to =20= >> be really >> good. >> >> Just don't know. >> >> Best regards, >> Seb >> >> --=20 >> S=E9bastien 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