Re: [O] org-use-property-inheritance not working?

2015-06-01 Thread Nicolas Goaziou
Rainer M Krug rai...@krugs.de writes:

 This means *a specific property* - or *any property*? In other words:
 can property A inherit from one level lower if property B is set in the
 current level?

It can.

 Then I think there is a bug. Look at the following example:

 #+PROPERTY: header-args  :tangle-mode (identity #o444)
 #+PROPERTY: header-args+ :eval no-export

 #+PROPERTY: header-args:R :session *R.EnergyBalance*


 * Make sure org-use-property-inheritance is nil

 #+begin_src emacs-lisp
  (setq org-use-property-inheritance nil)
 #+end_src

 #+RESULTS:

 Therefore from now on, we will only look at the current level and
 ignore properties set at lower levels - correct?

 * Without properties
 #+begin_src 
 13
 #+end_src

 ,
 | Properties:
 | :header-args:tangle-mode (identity #o444) :eval no-export
 | :header-args:nilnil
 | Switches:  
 | Header Arguments:
 | :cache  no
 | :eval   no-export
 | :exportscode
 | :hlines no
 | :noweb  no
 | :resultsreplace
 | :sessionnone
 | :tangle no
 | :tangle-mode292
 `

 * With Properties at level one
 :PROPERTIES:
 :header-args+: :tangle SetAtFirstLevel
 :header-args+: :output-dir ./output
 :END:

 #+begin_src R 
 13
 #+end_src

 ,
 | Lang: R
 | Properties:
 | :header-args:tangle-mode (identity #o444) :eval no-export :tangle 
 SetAtFirstLevel :output-dir ./output
 | :header-args:R  :session *R.EnergyBalance*
 | Header Arguments:
 | :cache  no
 | :eval   no-export
 | :exportscode
 | :hlines no
 | :noweb  no
 | :output-dir ./output
 | :resultsreplace
 | :session*R.EnergyBalance*
 | :tangle ./output/scripts/analysisCode.do.not.source.R
 | :tangle-mode292
 `

 ** Second level without properties
 These should now be the same as [[Without properties]] as 
 org-use-property-inheritance is nil.
 #+begin_src R 
 cat(13)
 #+end_src

 But it is the same as [[With Properties at level one]].
 ,
 | Lang: R
 | Properties:
 | :header-args:tangle-mode (identity #o444) :eval no-export :tangle 
 SetAtFirstLevel :output-dir ./output
 | :header-args:R  :session *R.EnergyBalance*
 | Header Arguments:
 | :cache  no
 | :eval   no-export
 | :exportscode
 | :hlines no
 | :noweb  no
 | :output-dir ./output
 | :resultsreplace
 | :session*R.EnergyBalance*
 | :tangle ./output/scripts/analysisCode.do.not.source.R
 | :tangle-mode292
 `

There's no bug. 

Babel activates inheritance on purpose, no matter what
`org-use-property-inheritance' says. See the last line of its docstring:
ob-core.el (in particular `org-babel-view-src-block-info') calls
`org-entry-get' with `t', not `selective'.

Really, `org-use-property-inheritance' is for your own properties. Org
ignores it to handle its own internal properties.

 Concerning property accumulation: I assume you mean the header-args+ -
 correct? Because I could not find the term accumu in the org manual.

Correct.

I don't think they have a name, but they should, because they are
a different beast than regular properties.

 Are these properties treated as a normal properties, and the same rules
 apply, or are there specific rules?

They follow specific rules. For example there can only be one property
A in a given property drawer, but there can be as many A+ as you want.
Also, (org-entry-get (point) A+) will not return something meaningful.


Regards,



Re: [O] org-use-property-inheritance not working?

2015-06-01 Thread Rainer M Krug
Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Rainer M Krug rai...@krugs.de writes:

 This means *a specific property* - or *any property*? In other words:
 can property A inherit from one level lower if property B is set in the
 current level?

 It can.

That's good.


 Then I think there is a bug. Look at the following example:

 #+PROPERTY: header-args  :tangle-mode (identity #o444)
 #+PROPERTY: header-args+ :eval no-export

 #+PROPERTY: header-args:R :session *R.EnergyBalance*


 * Make sure org-use-property-inheritance is nil

 #+begin_src emacs-lisp
  (setq org-use-property-inheritance nil)
 #+end_src

 #+RESULTS:

 Therefore from now on, we will only look at the current level and
 ignore properties set at lower levels - correct?

 * Without properties
 #+begin_src 
 13
 #+end_src

 ,
 | Properties:
 |:header-args:tangle-mode (identity #o444) :eval no-export
 |:header-args:nilnil
 | Switches:  
 | Header Arguments:
 |:cache  no
 |:eval   no-export
 |:exportscode
 |:hlines no
 |:noweb  no
 |:resultsreplace
 |:sessionnone
 |:tangle no
 |:tangle-mode292
 `

 * With Properties at level one
 :PROPERTIES:
 :header-args+: :tangle SetAtFirstLevel
 :header-args+: :output-dir ./output
 :END:

 #+begin_src R 
 13
 #+end_src

 ,
 | Lang: R
 | Properties:
 |:header-args:tangle-mode (identity #o444) :eval no-export :tangle 
 SetAtFirstLevel :output-dir ./output
 |:header-args:R  :session *R.EnergyBalance*
 | Header Arguments:
 |:cache  no
 |:eval   no-export
 |:exportscode
 |:hlines no
 |:noweb  no
 |:output-dir ./output
 |:resultsreplace
 |:session*R.EnergyBalance*
 |:tangle ./output/scripts/analysisCode.do.not.source.R
 |:tangle-mode292
 `

 ** Second level without properties
 These should now be the same as [[Without properties]] as 
 org-use-property-inheritance is nil.
 #+begin_src R 
 cat(13)
 #+end_src

 But it is the same as [[With Properties at level one]].
 ,
 | Lang: R
 | Properties:
 |:header-args:tangle-mode (identity #o444) :eval no-export :tangle 
 SetAtFirstLevel :output-dir ./output
 |:header-args:R  :session *R.EnergyBalance*
 | Header Arguments:
 |:cache  no
 |:eval   no-export
 |:exportscode
 |:hlines no
 |:noweb  no
 |:output-dir ./output
 |:resultsreplace
 |:session*R.EnergyBalance*
 |:tangle ./output/scripts/analysisCode.do.not.source.R
 |:tangle-mode292
 `

 There's no bug. 

 Babel activates inheritance on purpose, no matter what
 `org-use-property-inheritance' says. See the last line of its docstring:
 ob-core.el (in particular `org-babel-view-src-block-info') calls
 `org-entry-get' with `t', not `selective'.

 Really, `org-use-property-inheritance' is for your own properties. Org
 ignores it to handle its own internal properties.

Ah. That explains.I think it would be quite useful to add this to the
info section of org-use-property-inheritance.


 Concerning property accumulation: I assume you mean the header-args+ -
 correct? Because I could not find the term accumu in the org manual.

 Correct.

 I don't think they have a name, but they should, because they are
 a different beast than regular properties.


I agree - and I like the name accumulation properties or aggregation
properties.


 Are these properties treated as a normal properties, and the same rules
 apply, or are there specific rules?

 They follow specific rules. For example there can only be one property
 A in a given property drawer, but there can be as many A+ as you want.
 Also, (org-entry-get (point) A+) will not return something meaningful.

Thanks - things are much clearer now.

So there is no way at the moment to define a property in  lower level
and then overwrite it in a higher level? It might be only me, but I
think that would be quite a useful addition.

Thanks a lot for your help,

Rainer



 Regards,

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


signature.asc
Description: PGP signature


Re: [O] org-use-property-inheritance not working?

2015-06-01 Thread Nicolas Goaziou
Rainer M Krug rai...@krugs.de writes:

 Ah. That explains.I think it would be quite useful to add this to the
 info section of org-use-property-inheritance.

Patch welcome.

 I agree - and I like the name accumulation properties or aggregation
 properties.

Ditto. Any improvement to documentation is welcome. FWIW, I prefer the
latter.

 So there is no way at the moment to define a property in  lower level
 and then overwrite it in a higher level? It might be only me, but I
 think that would be quite a useful addition.

Could you provide a simple example of what you have in mind?


Regards,



Re: [O] org-use-property-inheritance not working?

2015-05-31 Thread Nicolas Goaziou
Rainer M Krug rai...@krugs.de writes:

 Looking at my example, it seems that the variable
 org-use-property-inheritance has no impact on the header arguments,
 i.e. no properties are inherited. So it seems that there is a bug, or a
 severe misunderstanding on my side what property inheritance means.

 From the help of the variable:

 ,
 | When nil, only the properties directly given in the current entry count.
 | When t, every property is inherited.  The value may also be a list of
 | properties that should have inheritance, or a regular expression matching
 | properties that should be inherited.
 `

 Reading this, and the fact that I get the same properties irrespective
 if I set org-use-property-inheritance to t or nil, I would assume that
 there is something not correct or consistent.

I think you are confused with property accumulation. However property
inheritance predates this feature and totally ignores it.

Inheritance is an answer to the question what should I do if the
property I'm looking for doesn't exist in the entry?. IOW, it only
kicks in, if at all, when property is /not found/ in current entry.

In your example, the property you're looking for is defined in every
entry, including the current one. Per above, Org doesn't even try to use
inheritance, and doesn't look at `org-use-property-inheritance'.


Regards,



Re: [O] org-use-property-inheritance not working?

2015-05-31 Thread Rainer M Krug
Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Rainer M Krug rai...@krugs.de writes:

 OK - but this behavior is not influenced by the variable
 org-use-property-inheritance. So what is the meaning of the variable
 then?

 The variable is checked when calling `org-entry-get' with a non-nil
 INHERIT optional argument.

 In this case `org-entry-get' calls `org-entry-get-with-inheritance'.

OK - let's move away from the programming in org and back to my question:

Looking at my example, it seems that the variable
org-use-property-inheritance has no impact on the header arguments,
i.e. no properties are inherited. So it seems that there is a bug, or a
severe misunderstanding on my side what property inheritance means.

From the help of the variable:

,
| When nil, only the properties directly given in the current entry count.
| When t, every property is inherited.  The value may also be a list of
| properties that should have inheritance, or a regular expression matching
| properties that should be inherited.
`

Reading this, and the fact that I get the same properties irrespective
if I set org-use-property-inheritance to t or nil, I would assume that
there is something not correct or consistent.

Rainer


 Regards,

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


signature.asc
Description: PGP signature


Re: [O] org-use-property-inheritance not working?

2015-05-30 Thread Nicolas Goaziou
Rainer M Krug rai...@krugs.de writes:

 OK - but this behavior is not influenced by the variable
 org-use-property-inheritance. So what is the meaning of the variable
 then?

The variable is checked when calling `org-entry-get' with a non-nil
INHERIT optional argument.

In this case `org-entry-get' calls `org-entry-get-with-inheritance'.

Regards,



Re: [O] org-use-property-inheritance not working?

2015-05-30 Thread Rainer M Krug
Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Hello,

 Charles C. Berry ccbe...@ucsd.edu writes:

 On Fri, 29 May 2015, Rainer M Krug wrote:

 Is this to be expected? I always thought, that the properties are
 hierarchical, and that the ones from the lower levels / headers are used
 as well?


 I would have thought this, too.

 Property inheritance doesn't work that way. 

 It only means that it will look higher in the hierarchy if current entry
 doesn't have the property you want. This is explained in
 `org-entry-get-with-inheritance' docstring:

   Get PROPERTY of entry or content at point, search higher levels if needed.
The search will stop at the first ancestor which has the property
defined.

OK - but this behavior is not influenced by the variable
org-use-property-inheritance. So what is the meaning of the variable
then?


Cheers,

Rainer


 Here, current entry has the property, so it ignores the one above.



 Regards,

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


signature.asc
Description: PGP signature


[O] org-use-property-inheritance not working?

2015-05-29 Thread Rainer M Krug
Consider this example:

I enable property inheritance with

(setq org-use-property-inheritance t)

--8---cut here---start-8---
#+PROPERTY: header-args  :tangle-mode (identity #o444)
#+PROPERTY: header-args+ :eval no-export

#+PROPERTY: header-args:R :session *R.EnergyBalance*


* Without properties
#+begin_src 
13
#+end_src

Result from (org-babel-view-src-block-info):
,
| Properties:
|   :header-args:tangle-mode (identity #o444) :eval no-export
|   :header-args:nilnil
| Switches:  
| Header Arguments:
|   :cache  no
|   :eval   no-export
|   :exportscode
|   :hlines no
|   :noweb  no
|   :resultsreplace
|   :sessionnone
|   :tangle no
|   :tangle-mode292
`

This is as expected.

* First Level
:PROPERTIES:
:header-args+: :tangle ./output/scripts/analysisCode.do.not.source.R
:header-args+: :output-dir ./output
:END:

#+begin_src R 
13
#+end_src

Result from (org-babel-view-src-block-info):
,
| Lang: R
| Properties:
|   :header-args:tangle-mode (identity #o444) :eval no-export :tangle 
./output/scripts/analysisCode.do.not.source.R :output-dir ./output
|   :header-args:R  :session *R.EnergyBalance*
| Header Arguments:
|   :cache  no
|   :eval   no-export
|   :exportscode
|   :hlines no
|   :noweb  no
|   :output-dir ./output
|   :resultsreplace
|   :session*R.EnergyBalance*
|   :tangle ./output/scripts/analysisCode.do.not.source.R
|   :tangle-mode292
`

Also as expected, the header arguments are appended

** Second level
:PROPERTIES:
:header-args:R: :session *R.Results.Simp*
:header-args+: :tangle ./output/scripts/graphs.SimplificationOfWindProfileFits.R
:END:

Now the problem comes:

#+begin_src R 
13
#+end_src

Result from (org-babel-view-src-block-info):
,
| Lang: R
| Properties:
|   :header-args:tangle-mode (identity #o444) :eval no-export :tangle 
./output/scripts/graphs.SimplificationOfWindProfileFits.R
|   :header-args:R  :session *R.Results.Simp*
| Header Arguments:
|   :cache  no
|   :eval   no-export
|   :exportscode
|   :hlines no
|   :noweb  no
|   :resultsreplace
|   :session*R.Results.Simp*
|   :tangle 
./output/scripts/graphs.SimplificationOfWindProfileFits.R
|   :tangle-mode292
`

The header arguments from Level One (:output-dir and :tangle) are not
there anymore and only the ones from the Second Level are used.

I would have expected the Level Two header arguments to be added to the
ones from Level One and the File wide?

--8---cut here---end---8---

Is this to be expected? I always thought, that the properties are
hierarchical, and that the ones from the lower levels / headers are used
as well?

Is this not the case, or id this a bug?

With property inheritance I would have expected the inheritance, but it
does not seem to make a difference?

Thanks,

Rainer

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


signature.asc
Description: PGP signature


Re: [O] org-use-property-inheritance not working?

2015-05-29 Thread Nicolas Goaziou
Hello,

Charles C. Berry ccbe...@ucsd.edu writes:

 On Fri, 29 May 2015, Rainer M Krug wrote:

 Is this to be expected? I always thought, that the properties are
 hierarchical, and that the ones from the lower levels / headers are used
 as well?


 I would have thought this, too.

Property inheritance doesn't work that way. 

It only means that it will look higher in the hierarchy if current entry
doesn't have the property you want. This is explained in
`org-entry-get-with-inheritance' docstring:

  Get PROPERTY of entry or content at point, search higher levels if needed.
   The search will stop at the first ancestor which has the property
   defined.

Here, current entry has the property, so it ignores the one above.


Regards,

-- 
Nicolas Goaziou



Re: [O] org-use-property-inheritance not working?

2015-05-29 Thread Charles C. Berry

On Fri, 29 May 2015, Rainer M Krug wrote:


Consider this example:

I enable property inheritance with

(setq org-use-property-inheritance t)


But it does not matter. See the docstring for `org-entry-get'. The setting 
used in `org-babel-view-src-block-info' for INHERIT is `t'.


I believe there is a problem with `org-entry-get'. Here is an ECM:

--8---cut here---start-8---

#+PROPERTY: aprop one

#+BEGIN_SRC emacs-lisp
  (org-entry-get (point) aprop t)
#+END_SRC

#+RESULTS:
: one

* x
  :PROPERTIES:
  :aprop+:   two
  :END:

#+BEGIN_SRC emacs-lisp
  (org-entry-get (point) aprop t)
#+END_SRC

#+RESULTS:
: one two

** y
  :PROPERTIES:
  :aprop+:   three
  :END:

#+BEGIN_SRC emacs-lisp
  (org-entry-get (point) aprop t)
#+END_SRC

#+RESULTS:
: one three

I expected 'one two three'

--8---cut here---end---8---


[much deleted]


Is this to be expected? I always thought, that the properties are
hierarchical, and that the ones from the lower levels / headers are used
as well?



I would have thought this, too.

[rest deleted]

Chuck