[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

--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

--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
--8<---------------cut here---------------end--------------->8---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]