Re: [O] :session question -- and changes to #+Property: syntax
Hopefully the simpler solution which uses the existing value of `org-babel-current-src-block-location' will prove sufficient (once someone implements it that is...). I'll implement it and see if this seems more useful than the current behaviour. If it is, then we'll have to decide if that new behaviour replaces the old one or yet another header argument or option switches between old and new. I guess it could be arranged so that the old-style properties kept the old behaviour and the new-style properties followed the new… I've pushed this to master, with documentation and testing. Old style property-based header arguments keep the old behaviour of looking up the properties at the point of source block definition for backwards compatibility and are now deprecated. The new header-args[:lang] properties use the location of the call as recorded in `org-babel-current-src-block-location'. This is great, thanks. I now see that we had different things in mind when talking about the location used when evaluating header arguments, however both were required and are now implemented. You implemented location-specific look up of header argument properties, I just pushed up location-specific evaluation of elisp embedded in header arguments as shown in the attached example file. Thanks, * First :PROPERTIES: :CUSTOM_ID: one :END: #+name: heading-id #+begin_src emacs-lisp :var point=(point) :var loc=(format %S org-babel-current-src-block-location) (format property %S at %d really %s (org-entry-get point CUSTOM_ID) point loc) #+end_src #+RESULTS: heading-id : property one at 70 really 70 * Second :PROPERTIES: :CUSTOM_ID: two :END: Call with all header arguments at the point of execution #+call: heading-id(point=(point)) #+RESULTS: heading-id(point=(point)) : property two at 433 really #marker at 433 in header-eval-location.org #+call: heading-id() #+RESULTS: heading-id() : property two at 582 really #marker at 582 in header-eval-location.org Another call from a code block rather than a call line. #+begin_src emacs-lisp :var in=heading-id() in #+end_src #+RESULTS: : property two at 762 really 762 -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] :session question -- and changes to #+Property: syntax
Eric Schulte writes: This is great, thanks. I now see that we had different things in mind when talking about the location used when evaluating header arguments, however both were required and are now implemented. Indeed. You implemented location-specific look up of header argument properties, I just pushed up location-specific evaluation of elisp embedded in header arguments as shown in the attached example file. Great, thank you. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] :session question -- and changes to #+Property: syntax
Achim Gratz writes: Eric Schulte writes: Oh, I understand now. I would also be happy with using *no* header arguments for this ephemeral elisp block if that is easily accomplished. I'll make a patch for testing this. I'll have to think about his some more. The info block produced from the header arguments is used in two places and there's another not-quite-exact copy of this in ob-exp that would need attention at the same time. Hopefully the simpler solution which uses the existing value of `org-babel-current-src-block-location' will prove sufficient (once someone implements it that is...). I'll implement it and see if this seems more useful than the current behaviour. If it is, then we'll have to decide if that new behaviour replaces the old one or yet another header argument or option switches between old and new. I guess it could be arranged so that the old-style properties kept the old behaviour and the new-style properties followed the new… I've pushed this to master, with documentation and testing. Old style property-based header arguments keep the old behaviour of looking up the properties at the point of source block definition for backwards compatibility and are now deprecated. The new header-args[:lang] properties use the location of the call as recorded in `org-babel-current-src-block-location'. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] :session question -- and changes to #+Property: syntax
Achim Gratz strom...@nexgo.de writes: Hi Eric, while starting to write up a test document I've found some behaviour when executing LOB calls that warrant discussion, I think: 1. The properties are evaluated at the site of the definition rather than the site of the call. I see what you're saying. The attached org-mode file demonstrates. * first :PROPERTIES: :CUSTOM_ID: first :END: #+name: heading-id #+begin_src emacs-lisp :var point=(point) (format %s at %d (org-entry-get point CUSTOM_ID) point) #+end_src #+RESULTS: heading-id : first at 53 * second :PROPERTIES: :CUSTOM_ID: second :END: #+call: heading-id(point=(point)) #+RESULTS: heading-id(point=(point)) : first at 53 This is simply how org-babel-process-params works, it jumps to the definition and then executes the source block there (this may be in another file even). 2. The evaluation of header arguments assumes emacs-lisp as a language. Yes, if one wants to execute a language other than Emacs-Lisp, then they should use a full fledged code block and pass a reference to that code block into the header argument. These two combined make it somewhat difficult to use properties to control the behaviour of LOB calls and understand what is happening and why. A workaround is to beam the source to the place of call via noweb syntax. This seem a little Rube Goldberg'ish to me. The first point could perhaps be addressed in a cleaner way by using org-babel-current-src-block-location when calling org-entry-get, but I'm not sure yet if it is always correctly set. I think the best way to handle the first issue would be to use the recently introduced `org-babel-current-src-block-location' variable, and jump back to that location when evaluation header arguments. Another thorny question is how to deal with another layer of calls that might evaluate properties again. If this is something we need to support, then we would want to turn the `org-babel-current-src-block-location' variable into a list onto which we push and pop locations. Presumably it would then be possible to evaluate each header argument at the correct location. A last option would be to introduce another header argument that can be used to inject the properties into the argument list of the call and, if set, would suppress any property evaluation in downstream calls. I'm not sure I fully understand this solution. For the second, I think that lob should be treated as a language for the purpose of anything *-default-header-args* so these settings can be independently controlled. I don't know what this means. I'm either mis-understanding your second issue, or I strongly disagree with it. I do not think it should be possible to embed arbitrary language source code into header arguments. Cheers, Thoughts, comments? Regards, Achim. -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] :session question -- and changes to #+Property: syntax
Eric Schulte writes: 2. The evaluation of header arguments assumes emacs-lisp as a language. Yes, if one wants to execute a language other than Emacs-Lisp, then they should use a full fledged code block and pass a reference to that code block into the header argument. […] For the second, I think that lob should be treated as a language for the purpose of anything *-default-header-args* so these settings can be independently controlled. I don't know what this means. I'm either mis-understanding your second issue, or I strongly disagree with it. I do not think it should be possible to embed arbitrary language source code into header arguments. I'm talking about the ephemeral source block that org-babel-lob-execute constructs. This is an emacs-lisp block and I see indeed no use of using a different language there, but I don't think it should necessarily use the default header arguments for all other emacs-lisp blocks. If these header arguments must be changeable, rather than simply fixed, my suggestion is to use org-babel-default-header-args:lob for that (and the moral equivalent for properties) so that setting some strange default haeder args for elisp blocks doesn't inadvertently take out LOB calls. These two combined make it somewhat difficult to use properties to control the behaviour of LOB calls and understand what is happening and why. A workaround is to beam the source to the place of call via noweb syntax. This seem a little Rube Goldberg'ish to me. That's actually a somewhat natural looking construct in Babel; certainly not the most elegant, but it gets the job done. I think the best way to handle the first issue would be to use the recently introduced `org-babel-current-src-block-location' variable, and jump back to that location when evaluation header arguments. I still have to convince myself that this works for this purpose, but yes, that'd be the most obvious solution if the properties should only be evaluated from the site of call. If anything, the resulting behaviour for nested Babel calls is more difficult to explain than what we have now however. Another thorny question is how to deal with another layer of calls that might evaluate properties again. If this is something we need to support, then we would want to turn the `org-babel-current-src-block-location' variable into a list onto which we push and pop locations. Presumably it would then be possible to evaluate each header argument at the correct location. That may not be as easy as you make it sound in the above sentence. Anyway, if we had such a (hypothetical) facility, I'm not sure if the additional control over the execution produces a net benefit over the increased complexity. A last option would be to introduce another header argument that can be used to inject the properties into the argument list of the call and, if set, would suppress any property evaluation in downstream calls. I'm not sure I fully understand this solution. Since it is another hypothetical solution, I'm not sure yet either. The idea is to record only the original call site in org-babel-current-src-block-location and hand (probably a list of) additional call sites or properties evaluated at those sites over to the source block as a header argument. This would have the benefit that the called function might be able to decide what to do with those, in particular overwrite or delete it. This allows yet more control, but see above. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: [O] :session question -- and changes to #+Property: syntax
Achim Gratz strom...@nexgo.de writes: Eric Schulte writes: 2. The evaluation of header arguments assumes emacs-lisp as a language. Yes, if one wants to execute a language other than Emacs-Lisp, then they should use a full fledged code block and pass a reference to that code block into the header argument. […] For the second, I think that lob should be treated as a language for the purpose of anything *-default-header-args* so these settings can be independently controlled. I don't know what this means. I'm either mis-understanding your second issue, or I strongly disagree with it. I do not think it should be possible to embed arbitrary language source code into header arguments. I'm talking about the ephemeral source block that org-babel-lob-execute constructs. This is an emacs-lisp block and I see indeed no use of using a different language there, but I don't think it should necessarily use the default header arguments for all other emacs-lisp blocks. If these header arguments must be changeable, rather than simply fixed, my suggestion is to use org-babel-default-header-args:lob for that (and the moral equivalent for properties) so that setting some strange default haeder args for elisp blocks doesn't inadvertently take out LOB calls. Oh, I understand now. I would also be happy with using *no* header arguments for this ephemeral elisp block if that is easily accomplished. These two combined make it somewhat difficult to use properties to control the behaviour of LOB calls and understand what is happening and why. A workaround is to beam the source to the place of call via noweb syntax. This seem a little Rube Goldberg'ish to me. That's actually a somewhat natural looking construct in Babel; certainly not the most elegant, but it gets the job done. I think the best way to handle the first issue would be to use the recently introduced `org-babel-current-src-block-location' variable, and jump back to that location when evaluation header arguments. I still have to convince myself that this works for this purpose, but yes, that'd be the most obvious solution if the properties should only be evaluated from the site of call. If anything, the resulting behaviour for nested Babel calls is more difficult to explain than what we have now however. I agree. This sounds like it would probably be overkill. Another thorny question is how to deal with another layer of calls that might evaluate properties again. If this is something we need to support, then we would want to turn the `org-babel-current-src-block-location' variable into a list onto which we push and pop locations. Presumably it would then be possible to evaluate each header argument at the correct location. That may not be as easy as you make it sound in the above sentence. Anyway, if we had such a (hypothetical) facility, I'm not sure if the additional control over the execution produces a net benefit over the increased complexity. Agreed. A last option would be to introduce another header argument that can be used to inject the properties into the argument list of the call and, if set, would suppress any property evaluation in downstream calls. I'm not sure I fully understand this solution. Since it is another hypothetical solution, I'm not sure yet either. The idea is to record only the original call site in org-babel-current-src-block-location and hand (probably a list of) additional call sites or properties evaluated at those sites over to the source block as a header argument. This would have the benefit that the called function might be able to decide what to do with those, in particular overwrite or delete it. This allows yet more control, but see above. Hopefully the simpler solution which uses the existing value of `org-babel-current-src-block-location' will prove sufficient (once someone implements it that is...). Cheers, Regards, Achim. -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] :session question -- and changes to #+Property: syntax
Eric Schulte writes: Oh, I understand now. I would also be happy with using *no* header arguments for this ephemeral elisp block if that is easily accomplished. I'll make a patch for testing this. Hopefully the simpler solution which uses the existing value of `org-babel-current-src-block-location' will prove sufficient (once someone implements it that is...). I'll implement it and see if this seems more useful than the current behaviour. If it is, then we'll have to decide if that new behaviour replaces the old one or yet another header argument or option switches between old and new. I guess it could be arranged so that the old-style properties kept the old behaviour and the new-style properties followed the new… 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
Re: [O] :session question -- and changes to #+Property: syntax
Hopefully the simpler solution which uses the existing value of `org-babel-current-src-block-location' will prove sufficient (once someone implements it that is...). I'll implement it and see if this seems more useful than the current behaviour. If it is, then we'll have to decide if that new behaviour replaces the old one or yet another header argument or option switches between old and new. I guess it could be arranged so that the old-style properties kept the old behaviour and the new-style properties followed the new… Introducing another header argument controlling this setting would add too much complexity. I think we either stick with the existing behavior or (preferably) change the default behavior. Thanks for taking these on! Regards, Achim. -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] :session question -- and changes to #+Property: syntax
Hi Achim On Tue, Jun 18, 2013 at 10:41 PM, Achim Gratz strom...@nexgo.de wrote: Hi Eric, while starting to write up a test document I've found some behaviour when executing LOB calls that warrant discussion, I think: 1. The properties are evaluated at the site of the definition rather than the site of the call. This is simply how org-babel-process-params works, it jumps to the definition and then executes the source block there (this may be in another file even). 2. The evaluation of header arguments assumes emacs-lisp as a language. I guess you do not mean the language of the source block, else see below for an example with shell. These two combined make it somewhat difficult to use properties to control the behaviour of LOB calls and understand what is happening and why. A workaround is to beam the source to the place of call via noweb syntax. The first point could perhaps be addressed in a cleaner way by using org-babel-current-src-block-location when calling org-entry-get, but I'm not sure yet if it is always correctly set. My intention is to ensure this with an ERT, see my patch here: http://lists.gnu.org/archive/html/emacs-orgmode/2013-06/msg00738.html [...] Michael
Re: [O] :session question -- and changes to #+Property: syntax
Hi Eric, while starting to write up a test document I've found some behaviour when executing LOB calls that warrant discussion, I think: 1. The properties are evaluated at the site of the definition rather than the site of the call. This is simply how org-babel-process-params works, it jumps to the definition and then executes the source block there (this may be in another file even). 2. The evaluation of header arguments assumes emacs-lisp as a language. These two combined make it somewhat difficult to use properties to control the behaviour of LOB calls and understand what is happening and why. A workaround is to beam the source to the place of call via noweb syntax. The first point could perhaps be addressed in a cleaner way by using org-babel-current-src-block-location when calling org-entry-get, but I'm not sure yet if it is always correctly set. Another thorny question is how to deal with another layer of calls that might evaluate properties again. A last option would be to introduce another header argument that can be used to inject the properties into the argument list of the call and, if set, would suppress any property evaluation in downstream calls. For the second, I think that lob should be treated as a language for the purpose of anything *-default-header-args* so these settings can be independently controlled. Thoughts, comments? 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
Re: [O] :session question -- and changes to #+Property: syntax
Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi Achim, Achim Gratz strom...@nexgo.de writes: Eric Schulte writes: As I recall I was fully in favor of applying these changes, however I am not qualified to address the changes to property behaviors. Hopefully someone who works more on that side of things can address those aspects. I am still hoping that one of the users that was asking for a way to specify header args at a finer granularity than just file variables would have a say. As a clarification: I'm not changing property syntax at all, I'm adding new properties that happen to have values that look like the header arguments to a source block. I've also implemented default (non-language-specific) header arguments just now. Unless you use the new property names none of the current behaviour changes (I do think the old properties should be removed some time later when people had time to convert their documents), but using the new property names will take precedence. This means if you specify 'cache yes' and also 'header-args :cache no' via properties, then the latter will take effect. Documentation and tests are still missing, but it shouldn't take too long I hope. I just applied your patches. Besides a quick test that went very well, I can not say much. The functionality is exactly what would help me a lot to separate session information for R and shell blocks. But given the example in the code, this is known to you. I would love to see that functionality in org and did not experience any problems after applying the patches. OK - I will change my syntax to the new property syntax and report back, likely not before middle of the week. Thanks, Rainer Regards, Andreas #secure method=pgpmime mode=sign -- Rainer M. Krug email: RMKrugatgmaildotcom
Re: [O] :session question -- and changes to #+Property: syntax
Achim Gratz strom...@nexgo.de writes: Eric Schulte writes: Great. Would you be willing to go ahead and apply these changes (including documentation)? If it upsets anyone we'll sort things out on the mailing list. All right, then. I've pushed the first part as it is a preparation for the actual change. I can push that second part as well, but I'll need another week or so for properly documenting it in the manual and setting up a test. Unless someone urgently wants to do something with it, I'd rather push these things together. As mentioned, I would then change my optional syntax of PROPERTY tomorrow. If you prefer earlier feedback, I could give it. Cheers, Rainer Regards, Achim. -- Rainer M. Krug email: RMKrugatgmaildotcom pgpVlMFfPiake.pgp Description: PGP signature
Re: [O] :session question -- and changes to #+Property: syntax
Rainer M Krug writes: As mentioned, I would then change my optional syntax of PROPERTY tomorrow. If you prefer earlier feedback, I could give it. An actual user document is much better than me trying to construct test cases (I'll still have do that later along with the documentation in the manual), so I've just pushed the actual code change to master. There's minimal documentation in the commit message. Any old-style properties (cache, session…) should still work, so please test this first before doing the changes to your documents. If you simply add new-style default properties (not specific to any language), simply use property header-args. This should _override_ any still existing old-style properties for the same header argument (please test this as well). Finally, the non-language-specific properties will be ignored if a language-specific property for the same header argument exists. 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
Re: [O] :session question -- and changes to #+Property: syntax
Eric Schulte writes: As I recall I was fully in favor of applying these changes, however I am not qualified to address the changes to property behaviors. Hopefully someone who works more on that side of things can address those aspects. Oh wait, now I understand what you're getting at, let me explain. The first patch that makes Org use the same regex in all places where a property is used does indeed change some behaviour, but not the syntax of the property line: :PROPERTY: VALUE where PROPERTY can contain any non-whitespace character (in correspondence to how the keyword PROPERTY is treated in org.el since it is not explicitly specified in org-element). However, there were other places in Org where a more restricted syntax for properties in property drawers was used, which would have precluded the use of : in property names and made it impossible to overwrite an inherited property from a #+PROPERTY: line that has such a property name. I've taken org-element as the authoritative source for the syntax and eliminated the other interpretations based on the fact that while the behaviour visible in the buffer (highlighting, prompts, etc.) would hint differently, the actual property handling was using the syntax used in org-element already. Hence if documents existed that had mistakenly made use of these differences, they were already broken and would be interpreted via the property API as they are now also shown after this change. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] :session question -- and changes to #+Property: syntax
Achim Gratz strom...@nexgo.de writes: Eric Schulte writes: As I recall I was fully in favor of applying these changes, however I am not qualified to address the changes to property behaviors. Hopefully someone who works more on that side of things can address those aspects. Oh wait, now I understand what you're getting at, let me explain. The first patch that makes Org use the same regex in all places where a property is used does indeed change some behaviour, but not the syntax of the property line: :PROPERTY: VALUE where PROPERTY can contain any non-whitespace character (in correspondence to how the keyword PROPERTY is treated in org.el since it is not explicitly specified in org-element). However, there were other places in Org where a more restricted syntax for properties in property drawers was used, which would have precluded the use of : in property names and made it impossible to overwrite an inherited property from a #+PROPERTY: line that has such a property name. I've taken org-element as the authoritative source for the syntax and eliminated the other interpretations based on the fact that while the behaviour visible in the buffer (highlighting, prompts, etc.) would hint differently, the actual property handling was using the syntax used in org-element already. Hence if documents existed that had mistakenly made use of these differences, they were already broken and would be interpreted via the property API as they are now also shown after this change. Great. Would you be willing to go ahead and apply these changes (including documentation)? If it upsets anyone we'll sort things out on the mailing list. There are stable releases precisely so that we can experiment interactively on the development head. Thanks, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] :session question -- and changes to #+Property: syntax
Eric Schulte writes: Great. Would you be willing to go ahead and apply these changes (including documentation)? If it upsets anyone we'll sort things out on the mailing list. All right, then. I've pushed the first part as it is a preparation for the actual change. I can push that second part as well, but I'll need another week or so for properly documenting it in the manual and setting up a test. Unless someone urgently wants to do something with it, I'd rather push these things together. 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
Re: [O] :session question -- and changes to #+Property: syntax
Achim Gratz strom...@nexgo.de writes: Achim Gratz writes: The change on the Babel side was just a few lines, but reconciling Org's notion of property syntax in various places proved to be more difficult. It's still not very well tested (it does survive the test suite obviously) and I'll need to write tests and documentation (help is welcome). Also, a new-style form of specifying header arguments for all languages (to then deprecate the old form) is missing at the moment since I'd like to get feedback on the language specific side first. No comments? As I recall I was fully in favor of applying these changes, however I am not qualified to address the changes to property behaviors. Hopefully someone who works more on that side of things can address those aspects. Thanks, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] :session question -- and changes to #+Property: syntax
Eric Schulte writes: As I recall I was fully in favor of applying these changes, however I am not qualified to address the changes to property behaviors. Hopefully someone who works more on that side of things can address those aspects. I am still hoping that one of the users that was asking for a way to specify header args at a finer granularity than just file variables would have a say. As a clarification: I'm not changing property syntax at all, I'm adding new properties that happen to have values that look like the header arguments to a source block. I've also implemented default (non-language-specific) header arguments just now. Unless you use the new property names none of the current behaviour changes (I do think the old properties should be removed some time later when people had time to convert their documents), but using the new property names will take precedence. This means if you specify 'cache yes' and also 'header-args :cache no' via properties, then the latter will take effect. Documentation and tests are still missing, but it shouldn't take too long I hope. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
