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

[Dan Davison <dandavison7@gmail.com>]

"Eric Schulte" <schulte.eric@gmail.com> writes:

> 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?

I agree, the things I was talking about don't end up being simpler in
terms of usage for this case. My thinking was that variable unsetting
might be something that would be required fairly rarely, and so it might
be worth appropriate to support it as part of a more general/powerful
mechanism tied into Org properties, or even that hook.

Before we proceed with the variable unsetting, could someone provide a
motivating example, just to convince ourselves that the extra features
are justified? (The conclusion of another message was that the torque
script example was more a motivating example for shebang/preamble
processing than for variable unsetting.)

Dan

>
> 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?
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode