From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric Schulte" Subject: Re: [BABEL] "unset" :var definitions for subtree Date: Fri, 11 Feb 2011 07:16:28 -0700 Message-ID: <87bp2imzb7.fsf@gmail.com> References: <4D500BEC.1080300@gmail.com> <87bp2koeir.fsf@gmail.com> <4D53A2D2.2080300@gmail.com> <87r5bfn8dg.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from [140.186.70.92] (port=36906 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pntnc-0000fb-S3 for emacs-orgmode@gnu.org; Fri, 11 Feb 2011 09:16:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pntna-00032B-Qz for emacs-orgmode@gnu.org; Fri, 11 Feb 2011 09:16:40 -0500 Received: from mail-iy0-f169.google.com ([209.85.210.169]:38158) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pntna-00031o-IH for emacs-orgmode@gnu.org; Fri, 11 Feb 2011 09:16:38 -0500 Received: by iyi20 with SMTP id 20so2676646iyi.0 for ; Fri, 11 Feb 2011 06:16:37 -0800 (PST) In-Reply-To: (Dan Davison's message of "Fri, 11 Feb 2011 12:19:22 +0000") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Dan Davison Cc: emacs-orgmode , Rainer M Krug 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?