* Difference :header-args: and :header-args+:? @ 2014-09-04 10:52 Rainer M Krug 2014-09-04 16:36 ` Aaron Ecay 0 siblings, 1 reply; 15+ messages in thread From: Rainer M Krug @ 2014-09-04 10:52 UTC (permalink / raw) To: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 715 bytes --] Hi I have a question concerning the property :header-args:. In addition to :header-args: there is also :header-args+:. 1) If I set some properties globally and in a subtree I want to *add* a *new* header argument - do I have to use the + or not? 2) If I set some properties globally and in a subtree I want to *change* a *single* header argument which *was set globally* - do I have to use the + or not? I am asking, because the + version is not mentioned in the manual and I have the feeling there are some inconsistencies, but I want to confirm if I understand this correctly before reporting these. Thanks, Rainer -- Rainer M. Krug email: Rainer<at>krugs<dot>de PGP: 0x0F52F982 [-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Difference :header-args: and :header-args+:? 2014-09-04 10:52 Difference :header-args: and :header-args+:? Rainer M Krug @ 2014-09-04 16:36 ` Aaron Ecay 2014-09-05 7:30 ` Rainer M Krug 0 siblings, 1 reply; 15+ messages in thread From: Aaron Ecay @ 2014-09-04 16:36 UTC (permalink / raw) To: Rainer M Krug, emacs-orgmode Hi Rainer, 2014ko irailak 4an, Rainer M Krug-ek idatzi zuen: > > Hi > > I have a question concerning the property :header-args:. In addition > to :header-args: there is also :header-args+:. > > > 1) If I set some properties globally and in a subtree I want to *add* a > *new* header argument - do I have to use the + or not? > > 2) If I set some properties globally and in a subtree I want to *change* > a *single* header argument which *was set globally* - do I have to use > the + or not? Are you aware that you can set individual header args as properties? Something like (at the file level): #+property: session *foo* or (at the subtree level): :PROPERTIES: :session: *foo* :END: This will likely be easier than trying to do surgery on the header-args property. -- Aaron Ecay ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Difference :header-args: and :header-args+:? 2014-09-04 16:36 ` Aaron Ecay @ 2014-09-05 7:30 ` Rainer M Krug 2014-09-06 1:18 ` Aaron Ecay 2014-09-08 14:17 ` Achim Gratz 0 siblings, 2 replies; 15+ messages in thread From: Rainer M Krug @ 2014-09-05 7:30 UTC (permalink / raw) To: emacs-orgmode; +Cc: Aaron Ecay [-- Attachment #1: Type: text/plain, Size: 1658 bytes --] Aaron Ecay <aaronecay@gmail.com> writes: > Hi Rainer, > > 2014ko irailak 4an, Rainer M Krug-ek idatzi zuen: >> >> Hi >> >> I have a question concerning the property :header-args:. In addition >> to :header-args: there is also :header-args+:. >> >> >> 1) If I set some properties globally and in a subtree I want to *add* a >> *new* header argument - do I have to use the + or not? >> >> 2) If I set some properties globally and in a subtree I want to *change* >> a *single* header argument which *was set globally* - do I have to use >> the + or not? > > Are you aware that you can set individual header args as properties? > Something like (at the file level): > > #+property: session *foo* > > or (at the subtree level): > > :PROPERTIES: > :session: *foo* > :END: > > This will likely be easier than trying to do surgery on the header-args > property. Absolutely - but this has been (unfortunately!!!!!!!) be deprecated: Quoted from the manual [1] : ,---- | [1] The deprecated syntax for default header argument properties, using | the name of the header argument as a property name directly, evaluates | the property as seen by the corresponding source block definition. This | behavior has been kept for backwards compatibility. `---- I was using this deprecated behavior and I was *very* happy with it, but I am trying to adjust to the new syntax. So how can I use the new syntax? Rainer Footnotes: [1] http://orgmode.org/manual/Header-arguments-in-Org-mode-properties.html#Header-arguments-in-Org-mode-properties -- Rainer M. Krug email: Rainer<at>krugs<dot>de PGP: 0x0F52F982 [-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Difference :header-args: and :header-args+:? 2014-09-05 7:30 ` Rainer M Krug @ 2014-09-06 1:18 ` Aaron Ecay 2014-09-08 10:36 ` Rainer M Krug 2014-09-08 14:27 ` Achim Gratz 2014-09-08 14:17 ` Achim Gratz 1 sibling, 2 replies; 15+ messages in thread From: Aaron Ecay @ 2014-09-06 1:18 UTC (permalink / raw) To: Rainer M Krug, emacs-orgmode Hi Rainer, 2014ko irailak 5an, Rainer M Krug-ek idatzi zuen: > > Absolutely - but this has been (unfortunately!!!!!!!) be deprecated: > > Quoted from the manual [1] : > > ,---- > | [1] The deprecated syntax for default header argument properties, using > | the name of the header argument as a property name directly, evaluates > | the property as seen by the corresponding source block definition. This > | behavior has been kept for backwards compatibility. > `---- > > I was using this deprecated behavior and I was *very* happy with it, but > I am trying to adjust to the new syntax. > > So how can I use the new syntax? Eric Schulte has said <http://mid.gmane.org/87wqce0w9n.fsf@gmail.com> that the deprecation of this feature is “premature”. I didn’t realize at the time that the deprecation was also included in the manual rather than just a code comment. Possibly it should be un-deprecated. Certainly I agree that the suggested replacement is less capable. Sorry I can’t help more. Maybe Eric or Achim (who introduced the deprecation) will comment. -- Aaron Ecay ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Difference :header-args: and :header-args+:? 2014-09-06 1:18 ` Aaron Ecay @ 2014-09-08 10:36 ` Rainer M Krug 2014-09-08 14:27 ` Achim Gratz 1 sibling, 0 replies; 15+ messages in thread From: Rainer M Krug @ 2014-09-08 10:36 UTC (permalink / raw) To: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 1385 bytes --] I would like to ping this question, as it is still bothering me and I could not find any explanation. Thanks, Rainer Aaron Ecay <aaronecay@gmail.com> writes: > Hi Rainer, > > 2014ko irailak 5an, Rainer M Krug-ek idatzi zuen: >> >> Absolutely - but this has been (unfortunately!!!!!!!) be deprecated: >> >> Quoted from the manual [1] : >> >> ,---- >> | [1] The deprecated syntax for default header argument properties, using >> | the name of the header argument as a property name directly, evaluates >> | the property as seen by the corresponding source block definition. This >> | behavior has been kept for backwards compatibility. >> `---- >> >> I was using this deprecated behavior and I was *very* happy with it, but >> I am trying to adjust to the new syntax. >> >> So how can I use the new syntax? > > Eric Schulte has said <http://mid.gmane.org/87wqce0w9n.fsf@gmail.com> > that the deprecation of this feature is “premature”. I didn’t realize > at the time that the deprecation was also included in the manual rather > than just a code comment. Possibly it should be un-deprecated. > > Certainly I agree that the suggested replacement is less capable. Sorry > I can’t help more. Maybe Eric or Achim (who introduced the deprecation) > will comment. -- Rainer M. Krug email: Rainer<at>krugs<dot>de PGP: 0x0F52F982 [-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Difference :header-args: and :header-args+:? 2014-09-06 1:18 ` Aaron Ecay 2014-09-08 10:36 ` Rainer M Krug @ 2014-09-08 14:27 ` Achim Gratz 2014-09-08 22:05 ` Aaron Ecay 2014-09-09 7:40 ` Rainer M Krug 1 sibling, 2 replies; 15+ messages in thread From: Achim Gratz @ 2014-09-08 14:27 UTC (permalink / raw) To: emacs-orgmode Aaron Ecay writes: > Eric Schulte has said <http://mid.gmane.org/87wqce0w9n.fsf@gmail.com> > that the deprecation of this feature is “premature”. I didn’t realize > at the time that the deprecation was also included in the manual rather > than just a code comment. Possibly it should be un-deprecated. It shouldn't, owing to a number of essentially un-fixable corner cases and its inherent non-scaleability. > Certainly I agree that the suggested replacement is less capable. Do you have an example of something that it cannot do (modulo the bugs and corners of the deprecated syntax)? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Difference :header-args: and :header-args+:? 2014-09-08 14:27 ` Achim Gratz @ 2014-09-08 22:05 ` Aaron Ecay 2014-09-09 8:20 ` Rainer M Krug 2014-09-09 13:40 ` Achim Gratz 2014-09-09 7:40 ` Rainer M Krug 1 sibling, 2 replies; 15+ messages in thread From: Aaron Ecay @ 2014-09-08 22:05 UTC (permalink / raw) To: Achim Gratz, emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 5076 bytes --] Hi Achim, 2014ko irailak 8an, Achim Gratz-ek idatzi zuen: > > Aaron Ecay writes: >> Eric Schulte has said <http://mid.gmane.org/87wqce0w9n.fsf@gmail.com> >> that the deprecation of this feature is “premature”. I didn’t realize >> at the time that the deprecation was also included in the manual rather >> than just a code comment. Possibly it should be un-deprecated. > > It shouldn't, owing to a number of essentially un-fixable corner cases > and its inherent non-scaleability. Can you say more about the corner cases? I looked for discussion on the mailing list around the time your changes were introduced. I only found a message <http://article.gmane.org/gmane.emacs.orgmode/73832> (in a thread about how/where #+call lines insert their results) that treats the change as a fait accompli, (“I agree that this didn't make all that much sense in the past, but with property evaluation and elisp argument evaluation now anchored to the point of call [...]”) I could have missed something, of course. As to the non-scalability, that should be fixed by some combination of the parser cache and retrieving all properties at once (via ‘org-entry-properties’) rather than ‘org-entry-get’-ing them one-by-one. There are a couple recent threads about this. Here’s one <http://mid.gmane.org/87tx5xunas.fsf@gmail.com> about a reimplementation of the property API functions in terms of the parser. Here <http://mid.gmane.org/CAAjq1mdioFFD-K9gX=DuCb205LYABqFKgObkFGYACiv0SttJ5A@mail.gmail.com> the speed tradeoffs of the two approaches are discussed. (IOW, as presently implemented the classical method is not scalable, but said unscalability is by no means “inherent”.) > >> Certainly I agree that the suggested replacement is less capable. > > Do you have an example of something that it cannot do (modulo the bugs > and corners of the deprecated syntax)? See the attached file for two examples, one related to #+call lines and one not. Again, can you say more about what you mean by the bugs and corners of the deprecated syntax? The #+call behavior doesn’t seem like a bug, but basically a difference in whether header args are dynamically (wrt point of call) or lexically (wrt point of definition) scoped. Dynamic vs. lexical scoping is not a bug, but a matter of taste/language design/etc. Most computer languages with which I’m familiar (Python, R, C, Scheme/Lisp, ...) use lexical scoping by default, and elisp has been slowly but steadily moving in that direction for years. Thus this new suggested dynamic-type behavior for header args is surprising to me. The first demonstration in the attachment (not related to #+calls) seems like a much clearer case of deficiency of the new system: an inability to inherit different args from different levels. (Please factor away from the nonsense strings in place of “yes” and “no” – I wanted to make it clear where each value was coming from, and assure that they were not being generated by default. Of course in a real use case the values for these header args would be “yes” and “no”. Also, one could also demonstrate the problem with header args that can take an arbitrary string value by design, like :session.) From your other mail: 2014ko irailak 8an, Achim Gratz-ek idatzi zuen: > > Rainer M Krug writes: >> Aaron Ecay <aaronecay@gmail.com> writes: [...] >>> Are you aware that you can set individual header args as properties? >>> Something like (at the file level): > > Are you aware that this doesn't quite do what you think it does, some of > the time, when things become more complex than your example? Again, can you say more about what you mean here? As a personal anecdote, I have never been surprised by the behavior of “classic” header arg properties. > >> I was using this deprecated behavior and I was *very* happy with it, but >> I am trying to adjust to the new syntax. >> >> So how can I use the new syntax? > > If you maybe had an example of what you're trying to do instead of > asking stuff about things you don't want to do? Otherwise, have a look > at > > <orgmode.git>/testing/examples/ob-header-arg-defaults.org I find the content of this file incredibly dense, and the suggestion of its use as documentation bordering on a joke. (Documentation may not exist, and that just means an area for improvement has been found. But it’s not as though we’re all going to read that file and suddenly understand what you mean.) It looks like it is trying to demonstrate inheritance and overriding of :var header args. I can’t figure out why the #+call in “Overwrite” gets go1, but the addition of “var+ to1” in “Accumulate” causes this to shift, not to “to1”, but to “ge1”. That is a very confusing interaction (to name just one). It’s also not clear to me how it relates to other header args, since vars supplement each other, whereas other types of header replace. -- Aaron Ecay [-- Attachment #2: foo5.org --] [-- Type: text/x-org, Size: 2425 bytes --] * Prelim Run this code first: #+begin_src emacs-lisp (require 'cl-lib) (defun awe-show-headers (&rest headers) (pp-to-string (save-excursion (goto-char org-babel-current-src-block-location) (cl-delete-if-not (lambda (pair) (memq (car pair) headers)) (nth 2 (org-babel-get-src-block-info 'light)))))) #+end_src #+RESULTS: : awe-show-headers * Case 1 ** The old way :PROPERTIES: :cache: foo :comments: bar :END: #+begin_src emacs-lisp (awe-show-headers :cache :comments) #+end_src #+RESULTS: : ((:comments . "bar yes") : (:cache . "foo no")) *** Subtree :PROPERTIES: :cache: quux :END: *Good*: we can inherit different header args from multiple levels in the hierarchy. #+begin_src emacs-lisp (awe-show-headers :cache :comments) #+end_src #+RESULTS: : ((:comments . "bar yes") : (:cache . "quux no")) ** The new way :PROPERTIES: :header-args: :cache foo :comments bar :END: #+begin_src emacs-lisp (awe-show-headers :cache :comments) #+end_src #+RESULTS: : ((:comments . "bar yes") : (:cache . "foo no")) *** Subtree :PROPERTIES: :header-args: :cache quux :END: *PROBLEM*: we don’t get =:comments foo= from parent headline (“The new way”) #+begin_src emacs-lisp (awe-show-headers :cache :comments) #+end_src #+RESULTS: : ((:comments . "yes") : (:cache . "quux no")) *** Subtree 2 :PROPERTIES: :header-args+: :cache quux :END: *PROBLEM*: we still don’t get =:comments foo= from parent headline even by using the + #+begin_src emacs-lisp (awe-show-headers :cache :comments) #+end_src #+RESULTS: : ((:comments . "yes") : (:cache . "quux no")) * Case 2 ** old way *** subtree :PROPERTIES: :var: awe-x=1 :END: #+name: call-me #+begin_src emacs-lisp (or (and (boundp 'awe-x) awe-x) "drat") #+end_src *** other subtree *Good*: the variable is bound from the site of definition, not call. #+call: call-me() #+RESULTS: : 1 ** new way *** subtree :PROPERTIES: :header-args: :var awe-x=1 :END: #+name: call-me-new #+begin_src emacs-lisp (or (and (boundp 'awe-x) awe-x) "drat") #+end_src *** other subtree *Bad*: the variable doesn’t get bound #+call: call-me-new() #+RESULTS: : drat ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Difference :header-args: and :header-args+:? 2014-09-08 22:05 ` Aaron Ecay @ 2014-09-09 8:20 ` Rainer M Krug 2014-09-09 13:57 ` Achim Gratz 2014-09-09 13:40 ` Achim Gratz 1 sibling, 1 reply; 15+ messages in thread From: Rainer M Krug @ 2014-09-09 8:20 UTC (permalink / raw) To: Achim Gratz; +Cc: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 7254 bytes --] Aaron Ecay <aaronecay@gmail.com> writes: > Hi Achim, > > 2014ko irailak 8an, Achim Gratz-ek idatzi zuen: >> >> Aaron Ecay writes: >>> Eric Schulte has said <http://mid.gmane.org/87wqce0w9n.fsf@gmail.com> >>> that the deprecation of this feature is “premature”. I didn’t realize >>> at the time that the deprecation was also included in the manual rather >>> than just a code comment. Possibly it should be un-deprecated. >> >> It shouldn't, owing to a number of essentially un-fixable corner cases >> and its inherent non-scaleability. I think that one main confusion comes fro the fact that by the new syntax, the previous properties in the header arguments have been demoted to sub-properties of the real property :header-args. So all operations on :header-args are operations on a *set of properties*. If this is the case, I would opt, in addition to the + operator, to have a - operator, which *removes* properties from the property set :header-args. I would actually call the + an "operation on an already defined property" and it should give an error message if the property is not set yet. So we have a property setter (:header-args) and property operators (header-args+) as well as (hopefully) :header-args-. By using this terminology, and that the property operators can only be called when the property has already been defined (which it usually is due to default values), the usage should be clearer. The same should apply to the :var as it also contains a set of entities. > > Can you say more about the corner cases? I looked for discussion on the > mailing list around the time your changes were introduced. I only found > a message <http://article.gmane.org/gmane.emacs.orgmode/73832> (in a > thread about how/where #+call lines insert their results) that treats > the change as a fait accompli, (“I agree that this didn't make all that > much sense in the past, but with property evaluation and elisp argument > evaluation now anchored to the point of call [...]”) > > I could have missed something, of course. > > As to the non-scalability, that should be fixed by some combination of > the parser cache and retrieving all properties at once (via > ‘org-entry-properties’) rather than ‘org-entry-get’-ing them one-by-one. > There are a couple recent threads about this. Here’s one > <http://mid.gmane.org/87tx5xunas.fsf@gmail.com> about a reimplementation > of the property API functions in terms of the parser. Here > <http://mid.gmane.org/CAAjq1mdioFFD-K9gX=DuCb205LYABqFKgObkFGYACiv0SttJ5A@mail.gmail.com> > the speed tradeoffs of the two approaches are discussed. (IOW, as > presently implemented the classical method is not scalable, but said > unscalability is by no means “inherent”.) > >> >>> Certainly I agree that the suggested replacement is less capable. >> >> Do you have an example of something that it cannot do (modulo the bugs >> and corners of the deprecated syntax)? > > See the attached file for two examples, one related to #+call lines and > one not. > > Again, can you say more about what you mean by the bugs and corners of > the deprecated syntax? The #+call behavior doesn’t seem like a bug, but > basically a difference in whether header args are dynamically (wrt point > of call) or lexically (wrt point of definition) scoped. Dynamic > vs. lexical scoping is not a bug, but a matter of taste/language > design/etc. Most computer languages with which I’m familiar (Python, R, > C, Scheme/Lisp, ...) use lexical scoping by default, and elisp has been > slowly but steadily moving in that direction for years. Thus this new > suggested dynamic-type behavior for header args is surprising to me. > > The first demonstration in the attachment (not related to #+calls) > seems like a much clearer case of deficiency of the new system: an > inability to inherit different args from different levels. (Please > factor away from the nonsense strings in place of “yes” and “no” – I > wanted to make it clear where each value was coming from, and assure > that they were not being generated by default. Of course in a real use > case the values for these header args would be “yes” and “no”. Also, > one could also demonstrate the problem with header args that can take > an arbitrary string value by design, like :session.) Initially I thought, to use :header-args+ instead of :header-args would work, but I was wrong (see below). ,---- | *** Subtree | :PROPERTIES: | :header-args+: :cache quux | :END: | | *PROBLEM*: we don’t get =:comments foo= from parent headline (“The new way”) | | #+begin_src emacs-lisp | (awe-show-headers :cache :comments) | #+end_src | | #+RESULTS: | : ((:comments . "") | : (:cache . "quux no")) `---- I guess one problem that the properties in :header-args are evaluated From left to right, and if one is found, this one is used? In case of inheritance (and adding a property via :header-args+) appends it, and if a same one exists before, the older one is used? > > From your other mail: > > 2014ko irailak 8an, Achim Gratz-ek idatzi zuen: >> >> Rainer M Krug writes: >>> Aaron Ecay <aaronecay@gmail.com> writes: > > [...] > >>>> Are you aware that you can set individual header args as properties? >>>> Something like (at the file level): >> >> Are you aware that this doesn't quite do what you think it does, some of >> the time, when things become more complex than your example? > > Again, can you say more about what you mean here? As a personal > anecdote, I have never been surprised by the behavior of “classic” > header arg properties. > >> >>> I was using this deprecated behavior and I was *very* happy with it, but >>> I am trying to adjust to the new syntax. >>> >>> So how can I use the new syntax? >> >> If you maybe had an example of what you're trying to do instead of >> asking stuff about things you don't want to do? Otherwise, have a look >> at >> >> <orgmode.git>/testing/examples/ob-header-arg-defaults.org > > I find the content of this file incredibly dense, and the suggestion > of its use as documentation bordering on a joke. (Documentation may > not exist, and that just means an area for improvement has been found. > But it’s not as though we’re all going to read that file and suddenly > understand what you mean.) It looks like it is trying to demonstrate > inheritance and overriding of :var header args. I can’t figure out > why the #+call in “Overwrite” gets go1, but the addition of “var+ to1” > in “Accumulate” causes this to shift, not to “to1”, but to “ge1”. > That is a very confusing interaction (to name just one). It’s also not > clear to me how it relates to other header args, since vars supplement > each other, whereas other types of header replace. I just looked at it - and there are may things going on which are way to complex to understand the basics of the use of :header-args (or rather working with property sets (or lists?) in general?) in org/ A still confused Rainer -- Rainer M. Krug email: Rainer<at>krugs<dot>de PGP: 0x0F52F982 [-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Difference :header-args: and :header-args+:? 2014-09-09 8:20 ` Rainer M Krug @ 2014-09-09 13:57 ` Achim Gratz 2014-09-09 19:19 ` Rainer M Krug 0 siblings, 1 reply; 15+ messages in thread From: Achim Gratz @ 2014-09-09 13:57 UTC (permalink / raw) To: emacs-orgmode Rainer M Krug writes: > If this is the case, I would opt, in addition to the + operator, to > have a - operator, which *removes* properties from the property set > :header-args. Properties don't work that way, they're just strings. > Initially I thought, to use :header-args+ instead of :header-args would > work, but I was wrong (see below). It's supposed to work, but doesn't due to a bug in the property API. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Difference :header-args: and :header-args+:? 2014-09-09 13:57 ` Achim Gratz @ 2014-09-09 19:19 ` Rainer M Krug 0 siblings, 0 replies; 15+ messages in thread From: Rainer M Krug @ 2014-09-09 19:19 UTC (permalink / raw) To: Achim Gratz; +Cc: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 798 bytes --] Achim Gratz <Stromeko@nexgo.de> writes: > Rainer M Krug writes: >> If this is the case, I would opt, in addition to the + operator, to >> have a - operator, which *removes* properties from the property set >> :header-args. > > Properties don't work that way, they're just strings. So the + adds a string to the end of the inherited (or before defined) string - correct? If this is the case, the same property can be mwentioned in the :header-qrgs string? > >> Initially I thought, to use :header-args+ instead of :header-args would >> work, but I was wrong (see below). > > It's supposed to work, but doesn't due to a bug in the property API. OK - good to know. Rainer > > > Regards, > Achim. -- Rainer M. Krug email: Rainer<at>krugs<dot>de PGP: 0x0F52F982 [-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Difference :header-args: and :header-args+:? 2014-09-08 22:05 ` Aaron Ecay 2014-09-09 8:20 ` Rainer M Krug @ 2014-09-09 13:40 ` Achim Gratz 2014-09-18 1:37 ` Aaron Ecay 1 sibling, 1 reply; 15+ messages in thread From: Achim Gratz @ 2014-09-09 13:40 UTC (permalink / raw) To: emacs-orgmode Aaron Ecay writes: > Can you say more about the corner cases? It's been quite some time since I looked at this, but inline calls were quirky for instance since their point of call is ill-defined. > As to the non-scalability, that should be fixed by some combination of > the parser cache and retrieving all properties at once (via > ‘org-entry-properties’) rather than ‘org-entry-get’-ing them > one-by-one. I don't think that will solve the problems. Note that the new syntax is dealing with default header args via the property facility just the same and the only real change is that it makes it possible to separate different Babel languages as well as defaults for all languages. > Most computer languages with which I’m familiar (Python, R, > C, Scheme/Lisp, ...) use lexical scoping by default, and elisp has been > slowly but steadily moving in that direction for years. Thus this new > suggested dynamic-type behavior for header args is surprising to me. There isn't even an execution model for Babel, so this discussion is going nowhere. Anyway, the idea was that when you look at a Babel invocation, you should be able to figure out the default header args at that point without actually having to trace the execution all the way down to the last recursion level. That's also important for caching since the cache signature for results doesn't take default headers into account. If you want to fix header args for certain block you can already do so by just specifying the header arg directly with the surce block. If you absolutely must use properties for this, you can simply do something like :var test=(org-entry-get nil "property" 'inherit) to pick up a property at the site of definition. But then at least it is explicit. > The first demonstration in the attachment (not related to #+calls) > seems like a much clearer case of deficiency of the new system: an > inability to inherit different args from different levels. No, it doesn't demonstrate this. Try to accumulate something to the commenr property via comment+ at the lower level and convince yourself it fails in exactly the same way: only the lowest level is returned as the value of the property. That looks like a bug in the property API. When getting the property it determines that the property is defined at the lowest level and then doesn't ascend into the upper ones. But even the examples in the manual show that the entry should add to the higher level definition of the property if the +-variant is used. The problem is that org-entry-get-with-inheritance uses org-entry-get (with the inheritance parameter set to nil), but has no provision to check for the "+" on the property. >> <orgmode.git>/testing/examples/ob-header-arg-defaults.org > > I find the content of this file incredibly dense, and the suggestion > of its use as documentation bordering on a joke. I wasn't offering it as documentation, only as a means to figure out what is or isn't supposed to be working. Plus it does boil down the whole topic into the smallest possible space. And if you do that you'll see that inheritance across multiple levels has not been tested so far (also not all possible combinations of shadowing), only inheritance between global and tree properties. > (Documentation may > not exist, and that just means an area for improvement has been found. > But it’s not as though we’re all going to read that file and suddenly > understand what you mean.) It looks like it is trying to demonstrate > inheritance and overriding of :var header args. I can’t figure out > why the #+call in “Overwrite” gets go1, but the addition of “var+ to1” > in “Accumulate” causes this to shift, not to “to1”, but to “ge1”. The most specific layer is ge1. While go1 is shadowed by to1 in the same layer, this is then again shadowed by ge1 (the more specific layer). Shadowing only happens in the same layer, which are overlaid only just before the invocation. Add :var+: "to3" and remove the t3="th3" definition to see this in action. > That is a very confusing interaction (to name just one). It’s also not > clear to me how it relates to other header args, since vars supplement > each other, whereas other types of header replace. The other header args are treated exactly the same, it's just that whatever their latest definition "wins" and you never see the other definitions. Properties are just strings right until babel interprets them as header args. If you print the complete properties as they get seen by the source block, you'll see this. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Difference :header-args: and :header-args+:? 2014-09-09 13:40 ` Achim Gratz @ 2014-09-18 1:37 ` Aaron Ecay 0 siblings, 0 replies; 15+ messages in thread From: Aaron Ecay @ 2014-09-18 1:37 UTC (permalink / raw) To: Achim Gratz, emacs-orgmode Hi Achim, 2014ko irailak 9an, Achim Gratz-ek idatzi zuen: > > Aaron Ecay writes: >> Can you say more about the corner cases? > > It's been quite some time since I looked at this, but inline calls were > quirky for instance since their point of call is ill-defined. Surely the point of call is just where they are written in the buffer? In any case, I’ll just take your word for it that there are unspecified difficulties. [...] >> Most computer languages with which I’m familiar (Python, R, >> C, Scheme/Lisp, ...) use lexical scoping by default, and elisp has been >> slowly but steadily moving in that direction for years. Thus this new >> suggested dynamic-type behavior for header args is surprising to me. > > There isn't even an execution model for Babel, so this discussion is > going nowhere. Anyway, the idea was that when you look at a Babel > invocation, you should be able to figure out the default header args at > that point without actually having to trace the execution all the way > down to the last recursion level. That’s one point of view. The other is that you should be able to specify a babel block’s behavior fully (i.e. including header args) and know that it will have that behavior no matter where it is called from. I think this system better promotes writing modular babel documents. > That's also important for caching since the cache signature for results > doesn't take default headers into account. But this issue is orthogonal to how the default headers are calculated, isn’t it? [...] > > No, it doesn't demonstrate this. Try to accumulate something to the > commenr property via comment+ at the lower level and convince yourself it > fails in exactly the same way: only the lowest level is returned as the > value of the property. > > That looks like a bug in the property API. When getting the property it > determines that the property is defined at the lowest level and then > doesn't ascend into the upper ones. But even the examples in the manual > show that the entry should add to the higher level definition of the > property if the +-variant is used. The problem is that > org-entry-get-with-inheritance uses org-entry-get (with the inheritance > parameter set to nil), but has no provision to check for the "+" on the > property. OK, I see. With this bug fixed, the new system probably has similar power to the old one indeed. (Modulo the point of definition vs. point of call issue.) [...] >> It looks like it is trying to demonstrate >> inheritance and overriding of :var header args. I can’t figure out >> why the #+call in “Overwrite” gets go1, but the addition of “var+ to1” >> in “Accumulate” causes this to shift, not to “to1”, but to “ge1”. > > The most specific layer is ge1. While go1 is shadowed by to1 in the > same layer, this is then again shadowed by ge1 (the more specific > layer). Shadowing only happens in the same layer, which are overlaid > only just before the invocation. Add :var+: "to3" and remove the > t3="th3" definition to see this in action. Sorry, I still don’t get it. I guess this is just a wart of the interaction between the two systems; let’s hope it disappears as soon as possible. -- Aaron Ecay ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Difference :header-args: and :header-args+:? 2014-09-08 14:27 ` Achim Gratz 2014-09-08 22:05 ` Aaron Ecay @ 2014-09-09 7:40 ` Rainer M Krug 2014-09-09 7:56 ` Rainer M Krug 1 sibling, 1 reply; 15+ messages in thread From: Rainer M Krug @ 2014-09-09 7:40 UTC (permalink / raw) To: Achim Gratz; +Cc: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 1591 bytes --] Achim Gratz <Stromeko@nexgo.de> writes: > Aaron Ecay writes: >> Eric Schulte has said <http://mid.gmane.org/87wqce0w9n.fsf@gmail.com> >> that the deprecation of this feature is “premature”. I didn’t realize >> at the time that the deprecation was also included in the manual rather >> than just a code comment. Possibly it should be un-deprecated. > > It shouldn't, owing to a number of essentially un-fixable corner cases > and its inherent non-scaleability. > >> Certainly I agree that the suggested replacement is less capable. > > Do you have an example of something that it cannot do (modulo the bugs > and corners of the deprecated syntax)? I agree with Achim, that the new header-args should be able to do the same as the old syntax, but I also think that it is more "clunky" and less easy to grasp how to do things. And the problem are a) the different ways that properties can be set (system wide, file wide, subtree level, code block - I might have forgotten some), b) the different levels and d) the inheritance rules of these levels (I assume inheritance is only in subtrees and code blocks in the subtree? How do file wide and system wide properties play here? (7.4. Property Inheritance, I am confused about the system wide and file wide properties? I know that this information is likely somewhere in the manual, but this whole issue of properties (especially when including the +) becomes rather confusing to me. Rainer > > > Regards, > Achim. -- Rainer M. Krug email: Rainer<at>krugs<dot>de PGP: 0x0F52F982 [-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Difference :header-args: and :header-args+:? 2014-09-09 7:40 ` Rainer M Krug @ 2014-09-09 7:56 ` Rainer M Krug 0 siblings, 0 replies; 15+ messages in thread From: Rainer M Krug @ 2014-09-09 7:56 UTC (permalink / raw) To: Achim Gratz; +Cc: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 2796 bytes --] Sorry about some points - see corrections below: Rainer M Krug <Rainer@krugs.de> writes: > Achim Gratz <Stromeko@nexgo.de> writes: > >> Aaron Ecay writes: >>> Eric Schulte has said <http://mid.gmane.org/87wqce0w9n.fsf@gmail.com> >>> that the deprecation of this feature is “premature”. I didn’t realize >>> at the time that the deprecation was also included in the manual rather >>> than just a code comment. Possibly it should be un-deprecated. >> >> It shouldn't, owing to a number of essentially un-fixable corner cases >> and its inherent non-scaleability. >> >>> Certainly I agree that the suggested replacement is less capable. >> >> Do you have an example of something that it cannot do (modulo the bugs >> and corners of the deprecated syntax)? > > I agree with Achim, that the new header-args should be able to do the > same as the old syntax, but I also think that it is more "clunky" and > less easy to grasp how to do things. > > And the problem are > > a) the different ways that properties can be set (system wide, file > wide, subtree level, code block - I might have forgotten some), > > b) the different levels and > > d) the inheritance rules of these levels (I assume inheritance is only > in subtrees and code blocks in the subtree? How do file wide and system > wide properties play here? (7.4. Property Inheritance, I am confused about the > system wide and file wide properties? d) the inheritance rules of these levels - In the manual it says it is off (7.4 Property Inheritance): ,---- | Org mode does not turn this on by default, because it can slow down | property searches significantly and is often not needed. However, if | you find inheritance useful, you can turn it on by setting the variable | `org-use-property-inheritance'. `---- But based on my experience it is on? Also in the examples it is on? Especially the inheritance with the combination of the + is confusing to me. If inheritance is on, the + should add an argument to the header-args property, while without the +, it should overwrite the inherited property? Or do they do the same? > > I know that this information is likely somewhere in the manual, but this > whole issue of properties (especially when including the +) becomes > rather confusing to me. > > Rainer > >> >> >> Regards, >> Achim. -- 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: Rainer@krugs.de Skype: RMkrug PGP: 0x0F52F982 [-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Difference :header-args: and :header-args+:? 2014-09-05 7:30 ` Rainer M Krug 2014-09-06 1:18 ` Aaron Ecay @ 2014-09-08 14:17 ` Achim Gratz 1 sibling, 0 replies; 15+ messages in thread From: Achim Gratz @ 2014-09-08 14:17 UTC (permalink / raw) To: emacs-orgmode Rainer M Krug writes: > Aaron Ecay <aaronecay@gmail.com> writes: >>> I have a question concerning the property :header-args:. In addition >>> to :header-args: there is also :header-args+:. Since essentially you're asking about property syntax, please read the corresponding chapter of the manual. >>> 1) If I set some properties globally and in a subtree I want to *add* a >>> *new* header argument - do I have to use the + or not? If you do that at the same level (old-non-lang-specific, non-lang-specific, lang-specific) then yes. >>> 2) If I set some properties globally and in a subtree I want to *change* >>> a *single* header argument which *was set globally* - do I have to use >>> the + or not? You can only override a header argument, not change it. Again, if you do this at the same level and there are other header arguments at that level, then the + variant is what you want. >> Are you aware that you can set individual header args as properties? >> Something like (at the file level): Are you aware that this doesn't quite do what you think it does, some of the time, when things become more complex than your example? > I was using this deprecated behavior and I was *very* happy with it, but > I am trying to adjust to the new syntax. > > So how can I use the new syntax? If you maybe had an example of what you're trying to do instead of asking stuff about things you don't want to do? Otherwise, have a look at <orgmode.git>/testing/examples/ob-header-arg-defaults.org and adapt to your needs. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2014-09-18 1:38 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-09-04 10:52 Difference :header-args: and :header-args+:? Rainer M Krug 2014-09-04 16:36 ` Aaron Ecay 2014-09-05 7:30 ` Rainer M Krug 2014-09-06 1:18 ` Aaron Ecay 2014-09-08 10:36 ` Rainer M Krug 2014-09-08 14:27 ` Achim Gratz 2014-09-08 22:05 ` Aaron Ecay 2014-09-09 8:20 ` Rainer M Krug 2014-09-09 13:57 ` Achim Gratz 2014-09-09 19:19 ` Rainer M Krug 2014-09-09 13:40 ` Achim Gratz 2014-09-18 1:37 ` Aaron Ecay 2014-09-09 7:40 ` Rainer M Krug 2014-09-09 7:56 ` Rainer M Krug 2014-09-08 14:17 ` Achim Gratz
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).