emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Sébastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org>
To: emacs-orgmode-mXXj517/zsQ@public.gmane.org
Subject: Re: Beamer presentation in the document
Date: Mon, 21 Jun 2010 11:34:11 +0200	[thread overview]
Message-ID: <87aaqopw4s.fsf@mundaneum.com> (raw)
In-Reply-To: 877hm6v9gs.fsf@gmail.com

Hi Eric,

"Eric Schulte" wrote:
> Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>>
>> Thanks a lot. I'll update tomorrow morning and test all of this.

Later than said... I come back to this.


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

OK. I did not take enough attention when reading. I thought you only preserved
comment lines between the call and the results. No, you were speaking of
comment lines between the #+results line and the actual result contents.


> 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.
>
> #+results: time
> # some comment about the time
> : Thu Jun 10 14:48:09 2010
> : Thu Jun 10 14:47:58 2010
>
> 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.

The above makes perfectly sense to me. If I were you, I would never allow
separation between the #+results line and the actual results, for the same
reason as you invoked: the #+results line is for identifying the actual
results.

Though, allowing comment lines is a great feature (even, if I don't use it yet).


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

I just updated Org this morning, and I can't remove the echo snippet from the
Org buffer. Do I have to do something extra regarding the lob?

--8<---------------cut here---------------start------------->8---
#+TITLE:     Complete Minimal Example
#+AUTHOR:    Sébastien Vauban
#+EMAIL:     wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org
#+DATE:      2010-06-21
#+LANGUAGE:  en_US

# This code block won't show in any export
#+source: echo
#+begin_src emacs-lisp :var tab='(("echo")) :exports none
  tab
#+end_src

* Document

** Results

   #+ATTR_LaTeX: align=lr
   #+tblname: rate-&-interests
   | Rate (%) |  Interests |
   |----------+------------|
   |     3.50 | 2564935.21 |
   |     4.50 | 3297773.83 |
   |     5.50 | 4030612.46 |
   |----------+------------|
   |    13.50 | 9893321.50 |
   #+TBLFM: @5$1=vsum(@-I..@-II);%.2f::@5$2=vsum(@-I..@-II);%.2f

* Presentation

  Amounts -- here is the table

  #+call: echo(tab=rate-&-interests) :exports results :hlines yes

  #+ATTR_LaTeX: align=lr

  This line does not hinder the "echo table" operation to succeed.

  #+results: echo(tab=rate-&-interests)
  | Rate (%) |  Interests |
  |----------+------------|
  |      3.5 | 2564935.21 |
  |      4.5 | 3297773.83 |
  |      5.5 | 4030612.46 |
  |----------+------------|
  |     13.5 |  9893321.5 |

  and the small explanation.
--8<---------------cut here---------------end--------------->8---

Two extra comments:

- Why don't you make `:hlines yes' the default value?  I guess, if we wanna
  copy a table, it's "as it is" by default, so with hlines and all...

- Not really a detail: the "echo" is perfect, but for the decimal precision.
  The `%.2f' spec is not preserved, as you can see above. That'd be great if
  it could be.

Best regards and *many thanks* as always,
  Seb

-- 
Sébastien Vauban


_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

  reply	other threads:[~2010-06-21  9:34 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
2010-06-21  9:34           ` Sébastien Vauban [this message]
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=87aaqopw4s.fsf@mundaneum.com \
    --to=wxhgmqzgwmuf-genee64ty+gs+fvcfc7uqw@public.gmane.org \
    --cc=emacs-orgmode-mXXj517/zsQ@public.gmane.org \
    /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).