Re: [BABEL] "unset" :var definitions for subtree

["Eric Schulte" <schulte.eric@gmail.com>]

Hi Dan,

Many interesting suggestions, but I don't see how any of them are
simpler (either conceptually or in terms of implementation) than
defining a way to "unset" a variable previously set at a higher level of
generality.  Is it the concept or the syntax of the previous suggestions
that you find objectionable?

I thought that either the :remove or :unset options suggested by Rainer
seemed intuitive.  I understand your point about not using a keyword,
and I agree (especially as our parsing is currently based on the
assumption that keywords are header arguments).  So maybe the
following...

this would unset all variables
#+begin_src emacs-lisp :var unset
  ;; code
#+end_src

this would unset only the variable A
#+begin_src emacs-lisp :var unset(A)
  ;; code
#+end_src

approaching this from another direction, we could have an :unset header
argument, which takes as arguments the names of other header arguments
to unset.  Could be used like this...

#+begin_src emacs-lisp :unset '(var noweb)
  ;; code
#+end_src

although it's not clear how to use such a construct to unset particular
variables...

So what do you think?  Should we explore syntactic options, or is there
something wrong with the very idea of a way of unsetting previously
bound header arguments?

Thanks -- Eric

More Comments in-line below:

[...]
>>
>> It would be nice to generalize whatever solution we apply across all
>> types of header argument (both for implementation and for user
>> simplicity).
>
> Some half thought-through suggestions. Sorry if this is a bit
> disorganized.
>
> I wonder whether we should be using Org property inheritance here. If
> it were possible to turn off property inheritance temporarily for the
> execution of the block, then it could be prevented from inheriting the
> header args that you don't want it to inherit.

Turning off property inheritance would break inheritance of *all* types
of header argument (which is probably not desirable) and would not be
useful for default values set in e.g., org-babel-default-header-args.

Also, how is this simpler than unsetting header arguments?

> Perhaps babel could offer a :bind header argument, which specifies the
> values of lisp variables in a let-binding which encloses the src block
> execution?
>

hmm, that is certainly an interesting Idea, and (separate from this
discussion of the need to unset variables) may be very useful in some
contexts -- although changing the lexical scope during the execution of
a code block probably wouldn't be normal usage.  In fact in many cases
this would have no effect because we explicitly ensure variables have
the value needed my our code, so often the user would end up with
situations like the following

;; babel code
(let ((some-org-variable 'user-desired-value))
  ;; more babel processing
  ;; ...
  ;; variable is about to be used
  (let ((some-org-variable 'babel-default-value)) ; <- we set explicitly
    ;; code that uses `some-org-variable'
    ))

>
> #+header: :bind org-babel-use-property-inheritance nil
> #+begin_src sh :tangle script.sh :shebang #!/bin/bash
> #$ -cwd
> #+end_src
>
> with a patch along these lines
>
> +(defvar org-babel-use-property-inheritance t
> +  "When looking for org-babel header arguments in in-buffer
> +  properties, this variable is passed as the INHERIT argument to
> +  the function `org-enrty-get'")
> +
>  (defvar org-file-properties)
>  (defun org-babel-params-from-properties (&optional lang)
>    "Retrieve parameters specified as properties.
> @@ -864,7 +870,7 @@ may be specified in the properties of the current outline entry."
>  	     (lambda (header-arg)
>  	       (and (setq val
>  			  (or (condition-case nil
> -				  (org-entry-get (point) header-arg t)
> +				  (org-entry-get (point) header-arg org-babel-use-property-inheritance)
>  				(error nil))
>  			      (cdr (assoc header-arg org-file-properties))))
>  		    (cons (intern (concat ":" header-arg))
>

So you dealt with the issue I noticed above by defining a separate
variable which the user *could* override with a `let'.  This would work
but would require
- rewriting of our code to use custom babel versions of many emacs variables
- requiring users to know both the normal and babel names of these
  variables to effectively modify them using this :bind header argument

Again, this seems much more complex than introducing a way to unset
header arguments.

[...]
>
> On a related note, I wonder whether the #+BABEL line should be
> re-implemented so that it works via setting org-file-properties?
> I.e. made equivalent to a #+PROPERTIES line?
>

Could we just remove #+Babel: lines entirely and use #+property: lines,
which I guess would mean reading in org-file-properties rather than
parsing #+Babel lines.  I agree this sounds like a good idea.

>
> Finally, a feature for babel power users could be to offer a hook
> function which allows modification of the source block data structure
> immediately prior to execution. In the babel code, source blocks are
> basically converted into an elisp data structure that tends to be called
> `info'. We could have org-babel-src-block-modification-hook each
> function of which would be passed the value of info and given the
> opportunity to change it just before execution. For anyone who's
> prepared to write elisp, that would permit a wide class of
> modifications, such as knocking out the :var variables.
>

I agree that this sounds powerful, but it is certainly not simple.  For
adding such complexity I would need to see a motivating example of where
this is needed.  When would this be easier than simply using :no-expand
and writing a code block verbatim as desired?