From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric Schulte" Subject: Re: Re: Beamer presentation in the document Date: Thu, 10 Jun 2010 14:55:31 -0700 Message-ID: <877hm6v9gs.fsf@gmail.com> References: <871vcg1rs0.fsf@mundaneum.com> <87sk4w2kgu.fsf@gmail.com> <87k4q7tiub.fsf@mundaneum.com> <87r5keolry.fsf@gmail.com> <87r5kevad6.fsf@mundaneum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from [140.186.70.92] (port=49185 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OMpis-0004ck-Gb for emacs-orgmode@gnu.org; Thu, 10 Jun 2010 17:55:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OMpiq-000735-Rv for emacs-orgmode@gnu.org; Thu, 10 Jun 2010 17:55:38 -0400 Received: from mail-pv0-f169.google.com ([74.125.83.169]:43060) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OMpiq-00072c-Id for emacs-orgmode@gnu.org; Thu, 10 Jun 2010 17:55:36 -0400 Received: by pva18 with SMTP id 18so397380pva.0 for ; Thu, 10 Jun 2010 14:55:34 -0700 (PDT) In-Reply-To: <87r5kevad6.fsf@mundaneum.com> (=?utf-8?Q?=22S=C3=A9bastien?= Vauban"'s message of "Thu, 10 Jun 2010 23:36:05 +0200") 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: =?utf-8?Q?S=C3=A9bastien?= Vauban Cc: emacs-orgmode@gnu.org Hi S=C3=A9bastien, S=C3=A9bastien Vauban writes: [...] >> for the first time a block is run the results will not be indented >> currently, although it would probably be worthwhile to default to indent= ing >> the results to the same level as the code block -- I'll add this as a TO= DO. > > Less important, even if nice when it will be there. > This should be possible now -- I've done a fairly thorough examination of the Org-babel code and tried to ensure that *everything* works well with indentation. It's very possible I've introduced some bugs in the process, please let me know if you find any. > >>> - less a detail than the 2 above: would it be possible to leave >>> some text between the `call' and the `results': in this example, so >>> that the `align' statement does not move after the table whenever >>> we `C-c C-c' the block for executing the `echo'? >> >> See the example below [1], is it sufficient to squeeze the #+results >> line in between the #+attr_latex line and the table? If not I'll update >> the results handling so that we allow preservation of comment lines >> between #+results and it's contents. > > Why only preserving comment lines? Why couldn't we imagine having the co= de > somewhere and the results much farther? Even twice the results -- that'd= be a > work around for the echo command. > This is another feature which may not be well enough advertised. If a code block is named, then we already allow the block and it's results to live arbitrarily far apart as long as they're in the same buffer e.g. [1]. That allows for separation of code and results which I think is an important feature. What I don't want to separate by too far is the #+results: name line, and the actual results. Mainly because the purpose of that #+results: line is to identify the results. Given that I think allowing a continuous string of comment lines between a #+results and it's target e.g. --8<---------------cut here---------------start------------->8--- #+results: time # some comment about the time : Thu Jun 10 14:48:09 2010 : Thu Jun 10 14:47:58 2010 --8<---------------cut here---------------end--------------->8--- is acceptable, but I think allowing arbitrary distance between them subverts the purpose of the #+results: line. I hope that sheds some light on this issue. Please let me know if you agree/disagree of if you do think comment separation like the above does make sense, in which case I'll add it to the queue. Cheers -- Eric > > >>>> I think I'll add the "echo" code block in the below example to the lib= rary >>>> of babel, so in the future this should work w/o having to include the = code >>>> block in the file. >>> >>> I think so as well. This is a must for enabling us to insert slides int= o a >>> document. And something nobody else (PowerPoint, even plain LaTeX?) can= do >>> (AFAIK). >> >> done. > > Thanks a lot. I'll update tomorrow morning and test all of this. > > >> Thanks for all the great feedback! -- Eric > > *Thank you very much*. Reporting is quite easy. Making it happen much les= s. > Thanks a lot for your continuous help, and quick resolution of my problem= s. > Thanks, it's always a please hacking on Org-mode. -- Eric > > Best regards, > Seb Footnotes:=20 [1]=20=20 --8<---------------cut here---------------start------------->8--- * top #+results: time : Thu Jun 10 14:48:09 2010 : Thu Jun 10 14:47:58 2010 ** subheading #+srcname: time #+begin_src emacs-lisp :results prepend (current-time-string) #+end_src --8<---------------cut here---------------end--------------->8---