Hi Sébastien, Sébastien Vauban <wxhgmqzgw...@spammotel.com> 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 indenting >> the results to the same level as the code block -- I'll add this as a TODO. > > 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 code > 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 library >>>> 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 into 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 less. > Thanks a lot for your continuous help, and quick resolution of my problems. > Thanks, it's always a please hacking on Org-mode. -- Eric > > Best regards, > Seb Footnotes: [1] --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--- _______________________________________________ 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
