emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Eric Schulte" <schulte.eric@gmail.com>
To: Rainer M Krug <r.m.krug@gmail.com>
Cc: emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: [BABEL] "unset" :var definitions for subtree
Date: Thu, 10 Feb 2011 09:48:27 -0700	[thread overview]
Message-ID: <87r5bfn8dg.fsf@gmail.com> (raw)
In-Reply-To: <4D53A2D2.2080300@gmail.com> (Rainer M. Krug's message of "Thu, 10 Feb 2011 09:33:22 +0100")

Rainer M Krug <r.m.krug@gmail.com> writes:

> On 02/10/2011 02:27 AM, Eric Schulte wrote:
>> Rainer M Krug <r.m.krug@gmail.com> writes:
>> 
>>> Hi
>>>
>>> For one project, I am usinr org to write submit scripte to a cluster
>>> runing torqu. The important bit in this is, that between the shebang and
>>> the code, no other executable line must occur. As I am using variables
>>> in org (:var) they will occur just after the shebang, which causes a
>>> problem for torque. So, my question is, is there a way to "unset"
>>> variables defined by using :var for a subtree?
>>>
>> 
>> Hi Rainer,
>> 
>> Interesting question... unfortunately I don't think that removing
>> variables from header arguments is possible under the current setup.
>> 
>> Perhaps in your case you could add a function to the post-tangle hook,
>> which recognizes when it is being called in a just-tangled torqu script
>> (maybe by searching for a series of #PBS lines), and then removes any
>> lines between the shebang and the first #PBS line?
>
> That is also an option - what I am using at the moment is to use
> :no-expand as a code block specific header argument. But this raises the
> other question:
>
> Can I set the :no-expand in a properties block? As far as I understand,
> in the properties block I have the argument and the value - but what do
> I do with :noexpand?
>
> :PROPERTIES:
> :var: A=13
> :no-expand
> :END:
>

You can just set it to "yes" or really any value you like (the value
will be ignored).  I did however have to add "no-expand" to the list of
header argument names searched for in property blocks -- I just pushed
up a patch to this effect.

>
>> 
>> More generally, I wonder what a natural method would be to allow
>> unsetting of pre-set header arguments for local blocks or subtrees?
>> This may only apply to the :var header argument, as most others have a
>> default setting which can be actively set.  If you have any ideas for a
>> natural syntax for such an operation I'd be happy to hear it.
>
> First solution (probably the easiest to implement) would be along the
> lines of the :no-expand header argument -
>
> :expand-var yes
> and
> :expand-var no
>
> This could possibly be expanded to
> :expand-var A B C
>
> which would expand only the variables A B and C
>
> One step further: one could define groups of variables, like
> :var-group X=A,B,C
> or a similar syntax
>
> and then
> :expand-var X
> would expand A B and C
>
> This all would not be real unset - but a possibility for unsetting would be
>
> :var B=
>
> or
>
> :var-unset B
>
> i.e. if no value is specified in :var, the variable will be removed
> (i.e. unset) - one could also use a null value (if it exists in elisp):
>
> :var B=(null)
>

Thanks for the ideas,

I think you're right that something along the lines of the above should
be the easiest to implement, however after reading these suggestions,
I'm thinking that more generally there are a couple of other header
arguments which could need to be unset, namely
- file
- dir
- session
- shebang
some of these (like session) accept a "none" value which has the effect
of un-setting the header argument.

It would be nice to generalize whatever solution we apply across all
types of header argument (both for implementation and for user
simplicity).  The simplest option would probably be to ensure that
setting any header argument to :none would remove all instances of that
header argument.  The only problem there is cases like var, where you
might not want to remove all :var's.  Maybe this could be expanded
s.t. :none could take arguments, e.g.

:header :none(A, B)

which would remove all instances of the "header" header argument whose
value is or is named "A" or "B"?  Or does that look too funky?

>
> But this raises another question of mine:
>
> I tried to use two :var headers in a properties block, but it only used
> the first - did I miss something here?
>

Nope, it appears that property blocks (like a hash) assume that there is
only one instance of each key->value pair, so once it is satisfied it
will quit looking for more instances.  Maybe the following alternative
will suffice

Best -- Eric

** two vars in a properties block -- not possible
   :PROPERTIES:
   :var:      test1=7
   :var:      test2=8
   :END:

#+begin_src emacs-lisp
  (message "test1=%S test2=%S" test1 test2)
#+end_src

results in Error
: let: Symbol's value as variable is void: test2

*** an alternative
    :PROPERTIES:
    :var:      tests=all-tests
    :END:

#+tblname: all-tests
- 7
- 8

#+begin_src emacs-lisp :var eric=89
  (message "test1=%S test2=%S" (first tests) (second tests))
#+end_src

#+results:
: test1=7 test2=8

  reply	other threads:[~2011-02-10 16:48 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-07 15:12 [BABEL] "unset" :var definitions for subtree Rainer M Krug
2011-02-10  1:27 ` Eric Schulte
2011-02-10  8:33   ` Rainer M Krug
2011-02-10 16:48     ` Eric Schulte [this message]
2011-02-11  9:00       ` Rainer M Krug
2011-02-11  9:32         ` Dan Davison
2011-02-11 10:22           ` Rainer M Krug
2011-02-11 11:55             ` Dan Davison
2011-02-11 12:29               ` Rainer M Krug
2011-02-11 13:49                 ` Dan Davison
2011-02-11 13:56                   ` Rainer M Krug
2011-02-12 22:54                   ` Eric Schulte
2011-02-11 12:19       ` Dan Davison
2011-02-11 12:58         ` Rainer M Krug
2011-02-11 13:41           ` Dan Davison
2011-02-11 14:05             ` Rainer M Krug
2011-02-12 23:12               ` Eric Schulte
2011-02-13  1:21                 ` Dan Davison
2011-02-13 18:28                   ` Eric Schulte
2011-02-13 21:38                     ` Dan Davison
2011-02-14 19:22                       ` Eric Schulte
2011-02-11 14:16         ` Eric Schulte
2011-02-11 14:45           ` Dan Davison
2011-02-12 23:13             ` Eric Schulte
2011-02-13  1:38               ` Dan Davison
2011-02-13 18:33                 ` Eric Schulte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r5bfn8dg.fsf@gmail.com \
    --to=schulte.eric@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=r.m.krug@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).