Marc-Oliver Ihm <marc-oliver....@online.de> 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/