emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Eric Schulte" <schulte.eric@gmail.com>
To: "Sébastien Vauban" <wxhgmqzgwmuf@spammotel.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Re: Beamer presentation in the document
Date: Thu, 10 Jun 2010 14:55:31 -0700	[thread overview]
Message-ID: <877hm6v9gs.fsf@gmail.com> (raw)
In-Reply-To: <87r5kevad6.fsf@mundaneum.com> ("Sébastien Vauban"'s message of "Thu, 10 Jun 2010 23:36:05 +0200")

Hi Sébastien,

Sébastien Vauban <wxhgmqzgwmuf@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---

  reply	other threads:[~2010-06-10 21:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-09  9:25 Beamer presentation in the document Sébastien Vauban
2010-06-09 17:18 ` Eric Schulte
2010-06-10  8:03   ` Sébastien Vauban
2010-06-10 17:11     ` Eric Schulte
2010-06-10 21:36       ` Sébastien Vauban
2010-06-10 21:55         ` Eric Schulte [this message]
2010-06-21  9:34           ` Sébastien Vauban
2010-06-10  8:36 ` Sébastien Vauban
2010-06-11  7:29   ` Sébastien Vauban
2010-06-21  9:46     ` Sébastien Vauban
2010-06-21 20:03       ` Eric S Fraga
2010-06-24  6:39       ` Carsten Dominik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877hm6v9gs.fsf@gmail.com \
    --to=schulte.eric@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=wxhgmqzgwmuf@spammotel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).