emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Dan Davison <dandavison7@gmail.com>
To: Eric Schulte <schulte.eric@gmail.com>
Cc: emacs-orgmode <emacs-orgmode@gnu.org>,
	Rainer M Krug <r.m.krug@gmail.com>
Subject: Re: [BABEL] "unset" :var definitions for subtree
Date: Sun, 13 Feb 2011 01:21:32 +0000	[thread overview]
Message-ID: <m1zkq0sp9f.fsf@94.197.159.103.threembb.co.uk> (raw)
In-Reply-To: <877hd44zin.fsf@gmail.com> (Eric Schulte's message of "Sat, 12 Feb 2011 16:12:27 -0700")

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

> [...]
>>> It seems that what you want to do can be described as disabling
>>> inheritance of the :var properties for a specific block. 
>>
>> Agreed - that would solve my problem.
>>
>>> So I'm suggesting that it may be more parsimonious to do this with
>>> the existing Org inheritance mechanisms than to introduce new babel
>>> header arguments specifically for this purpose.
>>
>> Agreed here.
>>
>
> If this is possible, then I'm all for it, however I do not think that it
> is currently possible to "disinherit" specific properties.  Note: do to
> the way babel collects properties, I don't think that temporarily
> changing the value of `org-use-property-inheritance' will be sufficient.
>
> [...]
>>>>
>>>> So how can I now define multiple variables?
>>> 
>>> I don't know :)
>>
>> Could Eric help here?
>>
>>> 
>>>> in a properties drawer multiple :var does not work? Could you give a
>>>> simple example how to define variables A and B?
>>> 
>>> Yes, I've always been a bit uncomfortable with this. As Eric says, Org
>>> properties are supposed to be a bit like a hash, with unique keys.
>>
>> So based on this, I can only define a single variable per properties drawer?
>>
>
> I'm not sure how this should be solved.  Would it be possible/desirable
> to allow multiple settings of the same key in Org-mode properties?  That
> seems like it could be a destructive change across all of Org-mode.

> Maybe we could extend the :var header argument to support the following
> syntax...
>
> #+begin_src emacs-lisp :var A=1 B=3
>   ;; code
> #+end_src
>
> or
>
> ** two vars in a properties block
>    :PROPERTIES:
>    :var:      test1=7 test2=8
>    :END:
>
> That shouldn't be overly difficult, and should solve our requirements.

Yes, that looks good. 

In the following Org file

---------------------------------------
#+property: :var a=1 b=2

* h1
  :PROPERTIES:
  :var: c=3
  :END:
** h11
   :PROPERTIES:
   :var: d=4 e=5 b=7
   :END:

#+begin_src sh :var f=6
# code here
#+end_src
---------------------------------------

if we follow programming languages by analogy then the behavior we
should aim for is for variables a,b,c,d,e to all be set in the src
block, with b having the value 7.

I've made a start on a patch to do that -- it involves treating :var
differently from other header args. Whereas normal property inheritance
searches up the tree until the specified property is encountered, my
patch searches up the tree to the root, collecting all the :var
assignments encountered.

So perhaps we should go for a solution involving both the new ":var a=1
b=2" syntax (to allow multiple :var in the same block), and the
pluralistic inheritance described above (to allow :var to be collected
from all levels in the hierarchy).

Dan



>
> Sound good? -- Eric
>
> _______________________________________________
> 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

  reply	other threads:[~2011-02-13  1:21 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
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 [this message]
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=m1zkq0sp9f.fsf@94.197.159.103.threembb.co.uk \
    --to=dandavison7@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=r.m.krug@gmail.com \
    --cc=schulte.eric@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).