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---
next prev parent 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).