emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Andreas Leha <andreas.leha@med.uni-goettingen.de>
To: emacs-orgmode@gnu.org
Subject: Re: evaluation context in call statements
Date: Thu, 27 Jun 2013 08:22:35 +0200	[thread overview]
Message-ID: <87d2r8hy38.fsf@med.uni-goettingen.de> (raw)
In-Reply-To: 87bo6sqhir.fsf@Rainer.invalid

Hi all


Achim Gratz <Stromeko@nexgo.de> writes:

> Eric Schulte writes:
>>>> My vote is for adding #+name support to call lines, and then handling
>>>> their results in the same manner as code block results.
>>
>> Achim Gratz <Stromeko@nexgo.de> writes:
>>> I'm not sure what this would entail other than replacing the call with
>>> its arguments with the name of the call in the results line.  But yes,
>>> that'd be a step forward, although you'd have to be careful when copying
>>> calls.
>>>
>>
>> This could work exactly as named source blocks work.  E.g.,
> [...]
>
> I see.  The problem then really is that #+CALL lines are currently
> "implicitly named" by copying their arguments to the results line.  If
> explicit naming is allowed, this implicit naming should go away or at
> least not be the default, IMHO.
>

[ ... ]

I did not follow this tread, so I just wanted to clarify:  You are talking
about making me to replace

--8<---------------cut here---------------start------------->8---
#+call: number_of_sth(origin="dataset1") :results table
#+call: number_of_sth(origin="dataset2") :results table
--8<---------------cut here---------------end--------------->8---

with

--8<---------------cut here---------------start------------->8---
#+name: call_number_of_sth_with_origin_dataset1
#+call: number_of_sth(origin="dataset1") :results table
#+name: call_number_of_sth_with_origin_dataset2
#+call: number_of_sth(origin="dataset2") :results table
--8<---------------cut here---------------end--------------->8---

?


Such change would make (some of) my orgmode files look rather
complicated.  The 'implicit' naming of call lines does make sense IMO,
as all that may distinguish two call lines really are the arguments.

I understand that there are problems with the current implementation of
call lines.  But I just want to say, that I would vote for not dropping
the implicit naming of call lines -- but for fixing their problems
instead.  An explicit name overriding the default implicit name would
be the preferable solution to me.

Regards,
Andreas

  reply	other threads:[~2013-06-27  6:22 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-25 17:34 evaluation context in call statements Rick Frankel
2013-06-25 19:21 ` Achim Gratz
2013-06-25 19:53   ` Achim Gratz
2013-06-25 20:06     ` Achim Gratz
2013-06-25 20:07     ` Michael Brand
2013-06-25 20:20       ` Achim Gratz
2013-06-25 20:55         ` Achim Gratz
2013-06-25 22:41         ` Eric Schulte
2013-06-26  6:29           ` Achim Gratz
2013-06-26 14:38             ` Rick Frankel
2013-06-26 15:13               ` Nicolas Goaziou
2013-06-26 15:29                 ` Rick Frankel
2013-06-26 15:49                   ` Eric Schulte
2013-06-26 15:06             ` Eric Schulte
2013-06-27  4:55               ` Achim Gratz
2013-06-27  6:22                 ` Andreas Leha [this message]
2013-06-27 14:27                   ` Achim Gratz
2013-06-27 23:12                     ` Andreas Leha
2013-06-30 22:24                 ` Eric Schulte
2013-07-01 10:23                   ` Michael Brand
2013-07-01 13:11                     ` Eric Schulte
2013-07-01 13:52                       ` Michael Brand
2013-07-01 14:10                         ` Eric Schulte
2013-06-26  8:38           ` Michael Brand
2013-06-26 14:54             ` Eric Schulte
2013-06-26 16:53               ` Michael Brand
2013-06-26 17:11                 ` Eric Schulte

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=87d2r8hy38.fsf@med.uni-goettingen.de \
    --to=andreas.leha@med.uni-goettingen.de \
    --cc=emacs-orgmode@gnu.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).