[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] [babel] Is there an elisp-way to see the header-arguments, that
From: |
Eric Schulte |
Subject: |
Re: [O] [babel] Is there an elisp-way to see the header-arguments, that are passed to a #+call-line ? |
Date: |
Sun, 05 Feb 2012 09:22:51 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.93 (gnu/linux) |
Marc-Oliver Ihm <address@hidden> writes:
> Hi again,
>
> is there an elisp-way to see the header-arguments, that are passed to a
> #+call-line ?
>
> (This relates to my previous question "[babel] #+call-line removes hlines and
> headings ?", but has
> shifted in subject, so I would like to start a new thread, which can be
> understood on its own ...)
>
> I have tried the internal variable "params", but that only gives me the
> header-arguments
> of the #+begin_src-block and NOT of the #+call-line.
>
> This is illustrated in the example below:
>
This was trickier than I expected to cobble together. See the example
in the attached Org-mode file in which a call line prints out its
parameters. Explanation of the mechanisms used are included.
Cheers,
#+Title: How to view the information present at a call line
This call line passes its in-buffer location to a code block. Notice
that the call to =(point)= in the call line is saved into a header
argument named =:my-point= and is then retrieved by the variable
initialization. This indirection is required because of /when/ and
/where/ the elisp forms in header arguments are evaluated, a simpler
call line like =#+call: show:((point))= would not work because the
form =(point)= would not be evaluated in the correct place.
#+call: show[:my-point (point)]((cdr (assoc :my-point (nth 2 info))))
:special-header "foo"
The special header argument =:special-header= may be seen in the
output below. The =results= variable is due to the way that call
lines are evaluated. During evaluation a call line is converted into
a trivial elisp code block of the form
: #+begin_src emacs-lisp :var results=called-function()
: results
: #+end_src
which is evaluated in place.
#+RESULTS: show[:my-point (point)]((cdr (assoc :my-point (nth 2 info))))
| (:var results ((:var nil)) ((:colname-names)) ((:rowname-names))
((:result-params replace)) ((:result-type . value)) ((:comments . )) ((:shebang
. )) ((:cache . no)) ((:padline . )) ((:noweb . yes)) ((:tangle . no))
((:exports . code)) ((:results . replace)) ((:padnewline . yes)) ((:hlines .
no)) ((:session . none))) |
| (:colname-names)
|
| (:rowname-names)
|
| (:result-params replace)
|
| (:result-type . value)
|
| (:comments . )
|
| (:shebang . )
|
| (:cache . no)
|
| (:padline . )
|
| (:noweb . yes)
|
| (:tangle . no)
|
| (:exports . code)
|
| (:results . replace)
|
| (:special-header . foo)
|
| (:padnewline . yes)
|
| (:hlines . no)
|
| (:session . none)
|
This code block visits the location of the call line, and calculates
the info using the same mechanisms used by =org-babel-lob-execute=.
#+name: show
#+begin_src emacs-lisp :var call-line-location=0
(let ((call-info (save-excursion
(goto-char call-line-location)
(org-babel-lob-get-info))))
(mapcar #'list
(org-babel-process-params
(org-babel-merge-params
org-babel-default-header-args
(org-babel-params-from-properties)
(org-babel-parse-header-arguments
(org-babel-clean-text-properties
(concat ":var results="
(mapconcat #'identity (butlast call-info) " "))))))))
#+end_src
>
> #+call: parameters() :colnames yes
>
> #+results: parameters()
> | :colname-names | nil |
> |----------------+------------------|
> | :rowname-names | nil |
> | :result-params | (silent replace) |
> | :result-type | value |
> | :comments | |
> | :shebang | |
> | :cache | no |
> | :padline | |
> | :noweb | no |
> | :tangle | no |
> | :exports | code |
> | :results | silent |
> | :session | none |
> | :padnewline | yes |
> | :hlines | yes |
> | :colnames | no |
> | :result-type | value |
> | :result-params | (replace) |
> | :rowname-names | nil |
> | :colname-names | nil |
>
> #+name: parameters
> #+begin_src emacs-lisp
> (mapcar (lambda (x) (list (car x) (cdr x))) params)
> #+end_src
>
> #+results: parameters
> | :colname-names | nil |
> | :rowname-names | nil |
> | :result-params | (replace) |
> | :result-type | value |
> | :comments | |
> | :shebang | |
> | :cache | no |
> | :padline | |
> | :noweb | no |
> | :tangle | no |
> | :exports | code |
> | :results | replace |
> | :colnames | no |
> | :hlines | yes |
> | :padnewline | yes |
> | :session | none |
>
>
> The #+call line calls a #+begin_src-block named "parameters", which simple
> dumps the
> content of the params-variable, which contains all the header arguments.
>
> If I pass ":colnames yes" as a header argument, I nevertheless get dumped
> "no" in the example !
> This is probably because the #+begin_src-block only has only access to its
> own header-arguments (via the variable "params").
>
> Therefore my question:
>
> Is there any way to access the header-arguments of the #+call-line within the
> #+begin_src-block ?
> Maybe with the "params" variable or maybe any other way ?
>
> The reason I need to know this: The value of the header-argument ":colnames"
> of the #+call-line
> governs, whether the #+begin_src-block is expected to return a table with or
> without column-names;
> so to react accordingly (and not surprise users) I need to know within the
> #+begin_src-block
> the value of the ":colnames" header-argument from the #+call-line.
>
> Thanx a lot !
>
> with kind regards, Marc-Oliver Ihm
>
> P.s.: Possible solutions I can think of:
> - Access the variable "params" not from the local scope but from the outer
> scope, however
> I do not know, if elisp allows this.
> - Pass the header-arguments of the #+call-line to the #+begin_src-block, but
> this would probably
> require a patch to babel.
> - Something even more elegant I just cannot figure out :-)
>
> Am 30.01.2012 17:10, schrieb Eric Schulte:
>
> >
> > To explain the cause (if not rationale) for the current behavior; when
> > executing a call line, an ephemeral code block is created at the point
> > of the call line. The result of the called function is passed into this
> > ephemeral block, and the output of the block is inserted into the
> > buffer.
> >
> > This is why call lines have *two* possible sets of header arguments, one
> > to pass to the original called code block, and one for local effect in
> > the ephemeral block.
> >
> > The reason the colnames header argument is required for the call line
> > and not the code block, is because hlines are only stripped when data
> > passes *into* a code block as a variable. In this case the 'hlines are
> > stripped when the table passes into the ephemeral code blocks.
> >
> > Hope the above is more illuminating that confusing,
> >
>
>
>
--
Eric Schulte
http://cs.unm.edu/~eschulte/