From: Eric Schulte <schulte.eric@gmail.com>
To: Achim Gratz <Stromeko@nexgo.de>
Cc: emacs-orgmode@gnu.org
Subject: Re: :session question -- and changes to #+Property: syntax
Date: Thu, 20 Jun 2013 12:31:53 -0600 [thread overview]
Message-ID: <87a9mkskfa.fsf@gmail.com> (raw)
In-Reply-To: <874ncsad3p.fsf@Rainer.invalid> (Achim Gratz's message of "Thu, 20 Jun 2013 19:47:22 +0200")
Achim Gratz <Stromeko@nexgo.de> writes:
> Eric Schulte writes:
>>> 2. The evaluation of header arguments assumes emacs-lisp as a language.
>>
>> Yes, if one wants to execute a language other than Emacs-Lisp, then they
>> should use a full fledged code block and pass a reference to that code
>> block into the header argument.
> […]
>>> For the second, I think that "lob" should be treated as a language for
>>> the purpose of anything *-default-header-args* so these settings can be
>>> independently controlled.
>>
>> I don't know what this means. I'm either mis-understanding your second
>> issue, or I strongly disagree with it. I do not think it should be
>> possible to embed arbitrary language source code into header arguments.
>
> I'm talking about the ephemeral source block that org-babel-lob-execute
> constructs. This is an emacs-lisp block and I see indeed no use of
> using a different language there, but I don't think it should
> necessarily use the default header arguments for all other emacs-lisp
> blocks. If these header arguments must be changeable, rather than
> simply fixed, my suggestion is to use org-babel-default-header-args:lob
> for that (and the moral equivalent for properties) so that setting some
> strange default haeder args for elisp blocks doesn't inadvertently take
> out LOB calls.
>
Oh, I understand now. I would also be happy with using *no* header
arguments for this ephemeral elisp block if that is easily accomplished.
>
>
>>> These two combined make it somewhat difficult to use properties to
>>> control the behaviour of LOB calls and understand what is happening and
>>> why. A workaround is to beam the source to the place of call via noweb
>>> syntax.
>>
>> This seem a little Rube Goldberg'ish to me.
>
> That's actually a somewhat natural looking construct in Babel; certainly
> not the most elegant, but it gets the job done.
>
>> I think the best way to handle the first issue would be to use the
>> recently introduced `org-babel-current-src-block-location' variable, and
>> jump back to that location when evaluation header arguments.
>
> I still have to convince myself that this works for this purpose, but
> yes, that'd be the most obvious solution if the properties should only
> be evaluated from the site of call. If anything, the resulting
> behaviour for nested Babel calls is more difficult to explain than what
> we have now however.
>
I agree. This sounds like it would probably be overkill.
>
>>> Another thorny question is how to deal with another layer of calls
>>> that might evaluate properties again.
>>
>> If this is something we need to support, then we would want to turn the
>> `org-babel-current-src-block-location' variable into a list onto which
>> we push and pop locations. Presumably it would then be possible to
>> evaluate each header argument at the correct location.
>
> That may not be as easy as you make it sound in the above sentence.
> Anyway, if we had such a (hypothetical) facility, I'm not sure if the
> additional control over the execution produces a net benefit over the
> increased complexity.
>
Agreed.
>
>>> A last option would be to introduce another header argument that can
>>> be used to inject the properties into the argument list of the call
>>> and, if set, would suppress any property evaluation in downstream
>>> calls.
>>
>> I'm not sure I fully understand this solution.
>
> Since it is another hypothetical solution, I'm not sure yet either. The
> idea is to record only the original call site in
> org-babel-current-src-block-location and hand (probably a list of)
> additional call sites or properties evaluated at those sites over to the
> source block as a header argument. This would have the benefit that the
> called function might be able to decide what to do with those, in
> particular overwrite or delete it. This allows yet more control, but
> see above.
>
Hopefully the simpler solution which uses the existing value of
`org-babel-current-src-block-location' will prove sufficient (once
someone implements it that is...).
Cheers,
>
>
>
> Regards,
> Achim.
--
Eric Schulte
http://cs.unm.edu/~eschulte
next prev parent reply other threads:[~2013-06-20 18:33 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-25 9:37 :session question Andreas Röhler
2013-03-25 23:58 ` Michael Gauland
2013-03-26 0:46 ` Eric Schulte
2013-03-26 8:37 ` Andreas Röhler
2013-03-26 9:12 ` Rainer M Krug
2013-03-26 9:23 ` Andreas Leha
2013-03-26 12:37 ` Eric Schulte
2013-03-26 12:44 ` Andreas Leha
2013-03-26 12:55 ` Achim Gratz
2013-03-26 15:31 ` Eric Schulte
2013-03-27 8:01 ` :session question - header argument setting Rainer M Krug
2013-03-27 8:35 ` Sebastien Vauban
2013-03-27 8:52 ` :session question Andreas Röhler
2013-03-27 9:27 ` Andreas Leha
2013-03-27 11:37 ` Andreas Röhler
2013-03-27 11:48 ` Nick Dokos
2013-03-27 12:18 ` Andreas Röhler
2013-03-27 12:22 ` Rainer M Krug
2013-03-27 12:47 ` Andreas Röhler
2013-03-27 12:43 ` Eric Schulte
2013-03-27 13:26 ` Andreas Röhler
2013-03-27 13:29 ` Andreas Leha
2013-03-27 15:47 ` Eric Schulte
2013-03-27 20:20 ` Andreas Leha
2013-03-27 20:35 ` Eric Schulte
2013-03-28 10:25 ` Andreas Leha
2013-03-28 13:06 ` John Hendy
2013-03-28 19:35 ` :session question - a simple PATCH Andreas Leha
2013-03-29 9:59 ` Achim Gratz
2013-03-29 14:38 ` Eric Schulte
2013-03-28 13:22 ` :session question John Hendy
2013-03-27 20:59 ` Andreas Röhler
2013-03-27 11:19 ` Andreas Leha
2013-04-28 15:46 ` Achim Gratz
2013-05-01 17:18 ` Eric Schulte
2013-05-01 17:36 ` Achim Gratz
2013-05-09 18:52 ` Achim Gratz
2013-06-07 16:15 ` Achim Gratz
2013-06-07 19:07 ` :session question -- and changes to #+Property: syntax Eric Schulte
2013-06-07 19:49 ` Achim Gratz
2013-06-07 20:22 ` Andreas Leha
2013-06-10 8:16 ` Rainer M Krug
2013-06-08 7:47 ` Achim Gratz
2013-06-08 18:08 ` Eric Schulte
2013-06-08 20:48 ` Achim Gratz
2013-06-10 8:21 ` Rainer M Krug
2013-06-10 19:16 ` Achim Gratz
2013-06-18 20:41 ` Achim Gratz
2013-06-19 10:10 ` Michael Brand
2013-06-20 16:27 ` Eric Schulte
2013-06-20 17:47 ` Achim Gratz
2013-06-20 18:31 ` Eric Schulte [this message]
2013-06-20 19:14 ` Achim Gratz
2013-06-20 19:28 ` Eric Schulte
2013-06-23 17:50 ` Achim Gratz
2013-06-25 14:20 ` Eric Schulte
2013-06-25 18:28 ` Achim Gratz
2013-06-10 8:14 ` :session question Rainer M Krug
2013-06-10 8:12 ` Rainer M Krug
2013-03-27 8:26 ` Andreas Röhler
2013-03-26 6:41 ` Andreas Röhler
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=87a9mkskfa.fsf@gmail.com \
--to=schulte.eric@gmail.com \
--cc=Stromeko@nexgo.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).