[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Orgmode] Re: Beamer presentation in the document
From: |
Eric Schulte |
Subject: |
Re: [Orgmode] Re: Beamer presentation in the document |
Date: |
Thu, 10 Jun 2010 14:55:31 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) |
Hi Sébastien,
Sébastien Vauban <address@hidden> 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---
[Orgmode] Re: Beamer presentation in the document, Sébastien Vauban, 2010/06/10