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
top post - sorry: I overlooked this thread somehow. Eric Schulte schulte.e...@gmail.com writes: Achim Gratz strom...@nexgo.de writes: Eric Schulte writes: If you mean that there should be new syntax for setting header arguments on a file or sub-tree basis w/o using file local variables, I'd be happy to apply a patch. I'm thinking that something like #+PROPERTY: header-args:R :session *R* :exports none should work. I hate to change syntax, but the syntax you mention above does look both appealing and natural. Even with working file local variables [1]. I agree - it looks very intuitive. I've checked that the property interface returns the data as expected, but I haven't implemented anything yet. It does not seem to be an overly difficult endeavour, however. That is very good news. With that portion working I would agree that this should be a fairly straightforward task. But importantly, there should be no way to set a default session name without also specifying the language, regardless of which way one tries to set this up. If you can think of a clean way to implement this then we should go for it. I doubt many existing configurations rely on this behavior. General settings for all languages should be effected by #+PROPERTY: header-args :results value :exports none and there'd be a list of header arguments (or specific values) that are either ignored or warned about when not associated with a particular language. BTW, I think the current property syntax for header arguments should be deprecated since it is the only place where the leading : is missing for those. Comments, thoughts? I think these are great ideas. Personally I'd love to see them implemented. Unfortunately I don't have time to work on an implementation currently. I'm surprised that none of the users who motivated this discussion have chimed in. Their opinions may be more Shame on my head - here are now a few comments (and praises) following in next emails. Cheers, Rainer valuable than my own in this regard (as I'm not a heavy #+Property user). Thanks for the clean and initially tested implementation idea! Regards, Achim. Footnotes: [1] Thanks to Bastien my patch allowing variables like `org-babel-default-header-args:R' to be set file-local has been applied to Emacs. -- Rainer M. Krug email: RMKrugatgmaildotcom pgpqMMj3gichR.pgp Description: PGP signature
Re: [O] :session question
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? Not tested, but it I like the idea and the syntax - very nice indeed. Cheers, Rainer Regards, Achim. -- Rainer M. Krug email: RMKrugatgmaildotcom pgpWK6YALK9zj.pgp Description: PGP signature
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
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? Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
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
Re: [O] :session question
Eric Schulte writes: I think these are great ideas. Personally I'd love to see them implemented. Unfortunately I don't have time to work on an implementation currently. I'm surprised that none of the users who motivated this discussion have chimed in. Their opinions may be more valuable than my own in this regard (as I'm not a heavy #+Property user). 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. With these caveats, here's the patchset: From fe5f9f46896939179f0163c2ce10f8738ebde709 Mon Sep 17 00:00:00 2001 From: Achim Gratz strom...@stromeko.de Date: Thu, 9 May 2013 19:47:59 +0200 Subject: [PATCH 1/2] org.el: improve org-property-re and use it throughout * lisp/org.el (org-property-re): Improve definition so that this regex can be used in all situations. Extend docstring with explanation of matching groups. (org-at-property-p): Implement using `org-element-at-point'. (org-entry-properties, org-buffer-property-keys, org-indent-line): Use `org-property-re' and adjust match group numbers accordingly. * lisp/org-element.el (org-element-node-property-parser): Use `org-property-re' and adjust match group numbers accordingly. Move `looking-at' out of the let clause to not rely on the unspecified evaluation order inside the let. --- lisp/org-element.el | 6 +++--- lisp/org.el | 40 2 files changed, 23 insertions(+), 23 deletions(-) diff --git a/lisp/org-element.el b/lisp/org-element.el index aafba88..f180f91 100644 --- a/lisp/org-element.el +++ b/lisp/org-element.el @@ -1973,11 +1973,11 @@ (defun org-element-node-property-parser (limit) containing `:key', `:value', `:begin', `:end' and `:post-blank' keywords. (save-excursion +(looking-at org-property-re) (let ((case-fold-search t) (begin (point)) - (key (progn (looking-at [ \t]*:\\(.*?\\):[ \t]+\\(.*?\\)[ \t]*$) - (org-match-string-no-properties 1))) - (value (org-match-string-no-properties 2)) + (key (org-match-string-no-properties 2)) + (value (org-match-string-no-properties 3)) (pos-before-blank (progn (forward-line) (point))) (end (progn (skip-chars-forward \r\t\n limit) (if (eobp) (point) (point-at-bol) diff --git a/lisp/org.el b/lisp/org.el index 1e28d93..b2e3836 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -6139,8 +6139,15 @@ (defun org-outline-level () (defvar org-font-lock-keywords nil) -(defconst org-property-re (org-re ^[ \t]*\\(:\\([-[:alnum:]_]+\\+?\\):\\)[ \t]*\\([^ \t\r\n].*\\)) - Regular expression matching a property line.) +(defconst org-property-re + ^\\(?4:[ \t]*\\)\\(?1::\\(?2:.*?\\):\\)[ \t]+\\(?3:[^ \t\r\n].*?\\)\\(?5:[ \t]*\\)$ + Regular expression matching a property line. +There are four matching groups: +1: :PROPKEY: including the leading and trailing colon, +2: PROPKEY without the leading and trailing colon, +3: PROPVAL without leading or trailing spaces, +4: the indentation of the current line, +5: trailing whitespace.) (defvar org-font-lock-hook nil Functions to be called for special font lock stuff.) @@ -15116,13 +15123,9 @@ (defun org-set-effort (optional value increment) (defun org-at-property-p () Is cursor inside a property drawer? (save-excursion -(beginning-of-line 1) -(when (looking-at (org-re ^[ \t]*\\(:\\([[:alpha:]][[:alnum:]_-]*\\):\\)[ \t]*\\(.*\\))) - (save-match-data ;; Used by calling procedures - (let ((p (point)) - (range (unless (org-before-first-heading-p) - (org-get-property-block - (and range (= (car range) p) ( p (cdr range +(when (equal 'node-property (car (org-element-at-point))) + (beginning-of-line 1) + (looking-at org-property-re (defun org-get-property-block (optional beg end force) Return the (beg . end) range of the body of the property drawer. @@ -15247,11 +15250,10 @@ (defun org-entry-properties (optional pom which specific) (setq range (org-get-property-block beg end)) (when range (goto-char (car range)) - (while (re-search-forward - (org-re ^[ \t]*:\\([[:alpha:]][[:alnum:]_-]*\\):[ \t]*\\(\\S-.*\\)?) + (while (re-search-forward org-property-re (cdr range) t) - (setq key (org-match-string-no-properties 1) - value (org-trim (or (org-match-string-no-properties 2) ))) + (setq key (org-match-string-no-properties 2) + value (org-trim (or (org-match-string-no-properties 3) ))) (unless (member key excluded) (push (cons key (or value )) props) (if clocksum @@ -15520,10
Re: [O] :session question
Achim Gratz strom...@nexgo.de writes: Eric Schulte writes: If you mean that there should be new syntax for setting header arguments on a file or sub-tree basis w/o using file local variables, I'd be happy to apply a patch. I'm thinking that something like #+PROPERTY: header-args:R :session *R* :exports none should work. I hate to change syntax, but the syntax you mention above does look both appealing and natural. Even with working file local variables [1]. I've checked that the property interface returns the data as expected, but I haven't implemented anything yet. It does not seem to be an overly difficult endeavour, however. That is very good news. With that portion working I would agree that this should be a fairly straightforward task. But importantly, there should be no way to set a default session name without also specifying the language, regardless of which way one tries to set this up. If you can think of a clean way to implement this then we should go for it. I doubt many existing configurations rely on this behavior. General settings for all languages should be effected by #+PROPERTY: header-args :results value :exports none and there'd be a list of header arguments (or specific values) that are either ignored or warned about when not associated with a particular language. BTW, I think the current property syntax for header arguments should be deprecated since it is the only place where the leading : is missing for those. Comments, thoughts? I think these are great ideas. Personally I'd love to see them implemented. Unfortunately I don't have time to work on an implementation currently. I'm surprised that none of the users who motivated this discussion have chimed in. Their opinions may be more valuable than my own in this regard (as I'm not a heavy #+Property user). Thanks for the clean and initially tested implementation idea! Regards, Achim. Footnotes: [1] Thanks to Bastien my patch allowing variables like `org-babel-default-header-args:R' to be set file-local has been applied to Emacs. -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] :session question
Eric Schulte writes: #+PROPERTY: header-args:R :session *R* :exports none I hate to change syntax, but the syntax you mention above does look both appealing and natural. Even with working file local variables [1]. OK, so let's settle for this. I've checked that the property interface returns the data as expected, but I haven't implemented anything yet. It does not seem to be an overly difficult endeavour, however. That is very good news. With that portion working I would agree that this should be a fairly straightforward task. […] I think these are great ideas. Personally I'd love to see them implemented. Unfortunately I don't have time to work on an implementation currently. I'll try to get something working. Not immediately, but I'll see when I can shoe it in. I'm surprised that none of the users who motivated this discussion have chimed in. Their opinions may be more valuable than my own in this regard (as I'm not a heavy #+Property user). Well, feedback from users would of course be welcome, but I don't expect anything really until there's some working code to show. Thanks for the clean and initially tested implementation idea! Thanks for your comments. [1] Thanks to Bastien my patch allowing variables like `org-babel-default-header-args:R' to be set file-local has been applied to Emacs. … but it will only be available from 24.4 onward. 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
Eric Schulte writes: If you mean that there should be new syntax for setting header arguments on a file or sub-tree basis w/o using file local variables, I'd be happy to apply a patch. I'm thinking that something like #+PROPERTY: header-args:R :session *R* :exports none should work. I've checked that the property interface returns the data as expected, but I haven't implemented anything yet. It does not seem to be an overly difficult endeavour, however. But importantly, there should be no way to set a default session name without also specifying the language, regardless of which way one tries to set this up. If you can think of a clean way to implement this then we should go for it. I doubt many existing configurations rely on this behavior. General settings for all languages should be effected by #+PROPERTY: header-args :results value :exports none and there'd be a list of header arguments (or specific values) that are either ignored or warned about when not associated with a particular language. BTW, I think the current property syntax for header arguments should be deprecated since it is the only place where the leading : is missing for those. Comments, thoughts? 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 - a simple PATCH
Am 28.03.2013 20:35, schrieb Andreas Leha: so it seems, currently, I (and John...) can not have both, /file local/ and /language local/ variables. - The emacs-lisp-block #+begin_src emacs-lisp (setq org-babel-default-header-args:R '((:session . org-R))) #+end_src works, of course, but sets the R-session globally. - The file-local variables (both way to set them) choke on the colon in the varible name. You could use eval: (setq etq org-babel-default-header-args:R '((:session . org-R))) instead of setting the variable directly. I do not know where to search for the reason, these variables work for Eric but not for me (and John...). I don't think they work for Eric if he tries to set them as file variable. So attached is a simple patch (search-and-replace) that renames all org-babel-default-header-args:* variables to org-babel-default-header-args-* In keeping with the spirit of the original naming I'd suggest switching from : to /. I still think this is a bug in how Emacs evaluates the local variables, but since it has been that way for ages it probably has become a feature. Regards, -- Achim. (on the road :-)
Re: [O] :session question - a simple PATCH
Achim Gratz strom...@nexgo.de writes: Am 28.03.2013 20:35, schrieb Andreas Leha: so it seems, currently, I (and John...) can not have both, /file local/ and /language local/ variables. - The emacs-lisp-block #+begin_src emacs-lisp (setq org-babel-default-header-args:R '((:session . org-R))) #+end_src works, of course, but sets the R-session globally. - The file-local variables (both way to set them) choke on the colon in the varible name. You could use eval: (setq etq org-babel-default-header-args:R '((:session . org-R))) instead of setting the variable directly. The above sets the value globally, the following should work for everyone. #+Title: Example The value in this buffer is... #+begin_src emacs-lisp org-babel-default-header-args:R #+end_src #+RESULTS: | (:session . bar) | # Local Variables: # eval: (setq-local org-babel-default-header-args:R '((:session . bar))) # End: I do not know where to search for the reason, these variables work for Eric but not for me (and John...). I don't think they work for Eric if he tries to set them as file variable. This was my fault. I miss-interpreted what was happening on my system, these aren't working for me either. So attached is a simple patch (search-and-replace) that renames all org-babel-default-header-args:* variables to org-babel-default-header-args-* In keeping with the spirit of the original naming I'd suggest switching from : to /. I still think this is a bug in how Emacs evaluates the local variables, but since it has been that way for ages it probably has become a feature. I agree that this is an Emacs bug. The attached patch fixes this bug, I suppose it should be submitted to the emacs-dev mailing list. # Bazaar merge directive format 2 (Bazaar 0.90) # revision_id: schulte.e...@gmail.com-20130328230926-46be4fl21w1g28wc # target_branch: http://bzr.savannah.gnu.org/r/emacs/trunk/ # testament_sha1: 969600ed8b879f2317f13e9f06968aafad4f786d # timestamp: 2013-03-28 17:09:47 -0600 # base_revision_id: monn...@iro.umontreal.ca-20130328163306-\ # 419khox8aneaoaxv # # Begin patch === modified file 'lisp/files.el' --- lisp/files.el 2013-03-24 06:42:25 + +++ lisp/files.el 2013-03-28 23:09:26 + @@ -3058,7 +3058,11 @@ (while (and (or (not mode-only) (not result)) ( (point) end)) -(unless (looking-at [ \t]*\\([^ \t\n:]+\\)[ \t]*:[ \t]*) + ;; The first of these next two regexs handles the + ;; case when a variable name includes a :, such as + ;; the `org-babel-default-header-args:R' variable. +(unless (or (looking-at [ \t]*\\([^ \t\n]?+\\)[ \t]*:[ \t]*) + (looking-at [ \t]*\\([^ \t\n:]+\\)[ \t]*:[ \t]*)) (message Malformed mode-line) (throw 'malformed-line nil)) (goto-char (match-end 0)) # Begin bundle IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWUbmhKQAAan/gAAyACBQ 0gAcD/BQA80t1o3vPXpy93vdCSSJiMIGmJNhCT9FNMninqBiY0CDJEniaZNJ6T0oYR6g AAyTEmSnhRmkDT1AAyDQB6hoADakmp5DRTam1DajamgA0PUAaAAAkkmkwmFPJijRkzRAAHqAGgAz S1WEfhTwKtT3Lzh0ptUwFljq3RvPzgDg4+hi9JNFWatAiacBNp3IkDC56rp8faNALW4WJH9ce0I4 Z3GPJC6C2Mb/dxhkm8cOfdIQ66fN3VUdhn4rW+w5H6/o92st+ja2A7xflnsZ06UJhX+y7kGzooqq 7W3cVuusjwpFyfSvT2myqcZODnTyKrAEMOEEaFAZApCpsCwwBUubxmdbx0obNO9dlFeiheV1LyDX grJNYIaa/OZTZslmmUv7NSjYTFSk0HuVurzo5oI0iIlY6e7GirGiM9qyooTyBr4gzgBdrWq+Udoe 0ELOU2gsNRtBGh50VBsck88MdLUo+pMxY1mqNkZFkcH8gVyOKsQDBAUtQV1RrZdWaaXBQEh+HE2Q kWgqVFNjBZWqkg2pKMldeUECX3XNq1r2CtxigWqRU0OaIkCCVas9HdcHxV+nLC8RBtcVmSA7SxMZ lwmjRRgRp2L4OsGG70jewey+edEe9QsThoPhM5SSi9uw8jxVmjPJsysa316MLrg4yithl8O1FIx2 kx7GAZzYWEYDCjyehjfA4NODyIKlnHwdst+b6fwry3abeeHKHYZrQ1gPqOmhUQTyKFRZZUcuSiqp fIVPxXdinnCWLtFgZlnmXMvCh31Y6oR6F1mRwbL00PMnsNGv4VJfH63gBQrSAFt2TFK9pSLnQIUs UEFLiW0xQw6o1drbk1zomZn0mlK6/l1Z1i/dpsovmyXGNUqwMRMb5wOO+4BiSsMIWzRm7CEds32t xSnyoRc8RLKQ0YK1qmSsgqRtgjenIw0zyJ+3ZXoWrebSiyCwcsp67r24c2dGLM4pHGjGLGjH7AP9 /hT1q4JHj3qme3tF4qRBYqISdCql/Uzk+8rA3UoDaUwY2PDLU/IFNql4g1W3xQa7jkVwazlnC1Xg bcAUimCaAIYmZiBzlVrw524UmJwhskwG4DTYolplKIXliWBxlgZsB4MzXkHiZKaaYz5CjEbRQJxB wxlfWTlI6mdWCDgOSQMw0X7QHH/SKlmxuydL7cEQqDEdmqoZsyqoSoGVLDqORLbUOwFGCE7rGkzW tXehClq6UIvm2YaBqeCIc0js7FE4NKr4IjM2IK2kU9OW5+kBzyGEE5o1MnSclPbVJUJUhMxGO6ak Kb5XiWBuQ0UmBkKFYFeIWApYzQralEo0UqwMw60f/i7kinChII3NCUg= Cheers, Regards, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] :session question
Hi Eric, Eric Schulte schulte.e...@gmail.com writes: Andreas Leha andreas.l...@med.uni-goettingen.de writes: [...] Is that just not working for me? And any ideas, what I could do about it? I have no good ideas. Is the `org-babel-default-header-args:R' variable defined on your system before you load this file? If not, maybe you should be sure to add (require 'ob-R) The variable is defined (value is nil). I added the (require 'ob-R) to my initialization nonetheless, but no avail. The value of `org-babel-default-header-args:R' stays nil. to your emacs initialization. If the : in the variable name is somehow confusing your Emacs, then possibly you could use the alternate format of specifying file local variables (see the info link in my attached example). I tried (the file is below). In this case I even get the question on unsafe variables. [...] Thanks for the suggestions anyway, Andreas PS: the file again: #+begin_org #+Title: Example #+Author: Eric Schulte For more information on file local variables see [[info:elisp#File%20Local%20Variables][info:elisp#File Local Variables]]. Because there is a default :session values assigned locally for R blocks we have the following. #+begin_src R x - 1 x #+end_src #+RESULTS: : 1 #+begin_src R x #+end_src #+RESULTS: But non-R code blocks do not have a default session value. #+begin_src sh date #+end_src #+RESULTS: : Mi 27. Mär 21:18:49 CET 2013 # Local Variables: # org-babel-default-header-args:R: ((:session . foo)) # End: #+end_org
Re: [O] :session question
On Thu, Mar 28, 2013 at 5:25 AM, Andreas Leha andreas.l...@med.uni-goettingen.de wrote: Hi Eric, Eric Schulte schulte.e...@gmail.com writes: Andreas Leha andreas.l...@med.uni-goettingen.de writes: [...] Is that just not working for me? And any ideas, what I could do about it? I have no good ideas. Is the `org-babel-default-header-args:R' variable defined on your system before you load this file? If not, maybe you should be sure to add (require 'ob-R) Is this the right way to require a language anymore? I thought it was: ;; active Babel languages (org-babel-do-load-languages 'org-babel-load-languages '((R . t))) (http://orgmode.org/worg/org-contrib/babel/languages.html) The variable is defined (value is nil). I added the (require 'ob-R) to my initialization nonetheless, but no avail. The value of `org-babel-default-header-args:R' stays nil. to your emacs initialization. If the : in the variable name is somehow confusing your Emacs, then possibly you could use the alternate format of specifying file local variables (see the info link in my attached example). I tried (the file is below). In this case I even get the question on unsafe variables. [...] Well that's good; it's trying to start a session. Thanks for the suggestions anyway, Andreas PS: the file again: #+begin_org #+Title: Example #+Author: Eric Schulte For more information on file local variables see [[info:elisp#File%20Local%20Variables][info:elisp#File Local Variables]]. Because there is a default :session values assigned locally for R blocks we have the following. #+begin_src R x - 1 x #+end_src #+RESULTS: : 1 #+begin_src R x #+end_src #+RESULTS: But non-R code blocks do not have a default session value. #+begin_src sh date #+end_src #+RESULTS: : Mi 27. Mär 21:18:49 CET 2013 # Local Variables: # org-babel-default-header-args:R: ((:session . foo)) # End: #+end_org Haven't really been following along, but this works for me (after execution): #+begin_src emacs-lisp (setq org-babel-default-header-args:R '((:session . org-R))) #+end_src These aren't: -*- org-babel-default-header-args:R: ((:session . foo)) -*- #-*- org-babel-default-header-args:R: ((:session . foo)) -*- There were a lot of suggestions made above and I've never used the -*-setting-*- syntax and am not searching the right things to find out more about how this is supposed to work. ETA: Ah, I had to re-open the file after adding this to the buffer to get it to recognize it: # Local Variables: # org-babel-default-header-args:R: ((:session . foo)) # End: This produces the same issue as you, Andreas: Wrong type argument: sequencep, R: Not sure. I'm on 8.0-pre (release_8.0-pre-193-gaa7b1e). John
Re: [O] :session question
On Wed, Mar 27, 2013 at 3:35 PM, Eric Schulte schulte.e...@gmail.com wrote: Andreas Leha andreas.l...@med.uni-goettingen.de writes: [...] Is that just not working for me? And any ideas, what I could do about it? I have no good ideas. Is the `org-babel-default-header-args:R' variable defined on your system before you load this file? If not, maybe you should be sure to add (require 'ob-R) to your emacs initialization. If the : in the variable name is somehow confusing your Emacs, then possibly you could use the alternate format of specifying file local variables (see the info link in my attached example). By alternate do you mean: # Local Variables: # stuff # End: vs. -*-stuff-*- ? If so, this isn't working for me either (I get malformed modeline): -*- org-babel-default-header-args:R: ((:session . foo)) -*- I read through the *info* on local file variables and both of the above seem like they should be correct. Wouldn't it be the colon? Emacs is looking for VAR:VALUE. Here's from files.el, which contains the function =hack-local-variables=. While not an elisper, this looks like it wouldn't figure out two colons: (while (and (not (eobp)) (or (not mode-only) (not result))) ;; Find the variable name; strip whitespace. (skip-chars-forward \t) (setq beg (point)) (skip-chars-forward ^:\n) (if (eolp) (error Missing colon in local variables entry)) (skip-chars-backward \t) Isn't this sort of saying, split up the var:value pair by starting at line beginning, going to the first =:=, and then looking for a newline? If so, I'd take the execution as trying to set: =org-babel-default-header-args= to a value of =R: ((:session . foo))= John I hope one of these works, aside from that I have no idea why our Emacs versions would differ in such fundamental behavior. Cheers, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] :session question - a simple PATCH
John Hendy jw.he...@gmail.com writes: [...] Haven't really been following along, but this works for me (after execution): #+begin_src emacs-lisp (setq org-babel-default-header-args:R '((:session . org-R))) #+end_src These aren't: -*- org-babel-default-header-args:R: ((:session . foo)) -*- #-*- org-babel-default-header-args:R: ((:session . foo)) -*- There were a lot of suggestions made above and I've never used the -*-setting-*- syntax and am not searching the right things to find out more about how this is supposed to work. ETA: Ah, I had to re-open the file after adding this to the buffer to get it to recognize it: # Local Variables: # org-babel-default-header-args:R: ((:session . foo)) # End: This produces the same issue as you, Andreas: Wrong type argument: sequencep, R: Not sure. I'm on 8.0-pre (release_8.0-pre-193-gaa7b1e). John Hi all, so it seems, currently, I (and John...) can not have both, /file local/ and /language local/ variables. - The emacs-lisp-block #+begin_src emacs-lisp (setq org-babel-default-header-args:R '((:session . org-R))) #+end_src works, of course, but sets the R-session globally. - The file-local variables (both way to set them) choke on the colon in the varible name. I do not know where to search for the reason, these variables work for Eric but not for me (and John...). So attached is a simple patch (search-and-replace) that renames all org-babel-default-header-args:* variables to org-babel-default-header-args-* I do not see any problems with this renaming, but as I have only limited elisp, that might not mean too much. This fixes the issue for me at the cost of breaking other people's setup if they use org-babel-default-header-args:* variants. What do you think? Regards, Andreas From 91965d0fc8820f9c0b68728368d3d8062d8c49ef Mon Sep 17 00:00:00 2001 From: Andreas Leha andr...@lehas.net Date: Thu, 28 Mar 2013 16:45:33 +0100 Subject: [PATCH] Renamed vars org-babel-default-header-args:* to org-babel-default-header-args-* This makes them usable in file local variables. --- contrib/lisp/ob-eukleides.el |2 +- contrib/lisp/ob-fomus.el |2 +- contrib/lisp/ob-julia.el |2 +- contrib/lisp/ob-mathomatic.el|2 +- contrib/lisp/ob-tcl.el |2 +- lisp/ob-C.el |2 +- lisp/ob-R.el |2 +- lisp/ob-asymptote.el |2 +- lisp/ob-calc.el |2 +- lisp/ob-clojure.el |2 +- lisp/ob-core.el |4 ++-- lisp/ob-css.el |2 +- lisp/ob-ditaa.el |2 +- lisp/ob-dot.el |2 +- lisp/ob-emacs-lisp.el|2 +- lisp/ob-exp.el |2 +- lisp/ob-fortran.el |2 +- lisp/ob-gnuplot.el |2 +- lisp/ob-haskell.el |2 +- lisp/ob-io.el|2 +- lisp/ob-js.el|2 +- lisp/ob-latex.el |2 +- lisp/ob-ledger.el|2 +- lisp/ob-lilypond.el |6 +++--- lisp/ob-lisp.el |2 +- lisp/ob-makefile.el |2 +- lisp/ob-maxima.el|2 +- lisp/ob-mscgen.el|2 +- lisp/ob-ocaml.el |2 +- lisp/ob-octave.el|4 ++-- lisp/ob-org.el |2 +- lisp/ob-perl.el |2 +- lisp/ob-picolisp.el |2 +- lisp/ob-plantuml.el |2 +- lisp/ob-python.el|2 +- lisp/ob-ruby.el |2 +- lisp/ob-sass.el |2 +- lisp/ob-scala.el |2 +- lisp/ob-scheme.el|2 +- lisp/ob-screen.el|4 ++-- lisp/ob-sh.el|2 +- lisp/ob-shen.el |2 +- lisp/ob-sql.el |2 +- lisp/ob-sqlite.el|2 +- testing/lisp/test-ob-lilypond.el |8 45 files changed, 53 insertions(+), 53 deletions(-) diff --git a/contrib/lisp/ob-eukleides.el b/contrib/lisp/ob-eukleides.el index e25ed1c..3747b4e 100644 --- a/contrib/lisp/ob-eukleides.el +++ b/contrib/lisp/ob-eukleides.el @@ -37,7 +37,7 @@ (require 'ob) (require 'ob-eval) -(defvar org-babel-default-header-args:eukleides +(defvar org-babel-default-header-args-eukleides '((:results . file) (:exports . results)) Default arguments for evaluating a eukleides source block.) diff --git a/contrib/lisp/ob-fomus.el b/contrib/lisp/ob-fomus.el index 58183fb..8914843 100644 --- a/contrib/lisp/ob-fomus.el +++ b/contrib/lisp/ob-fomus.el @@ -42,7 +42,7 @@ (require 'ob) (require 'ob-eval) -(defvar org-babel-default-header-args:fomus +(defvar org-babel-default-header-args-fomus '((:results . file) (:exports . results)) Default arguments to use when
Re: [O] :session question - header argument setting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/03/13 16:31, Eric Schulte wrote: Achim Gratz strom...@nexgo.de writes: Am 26.03.2013 13:37, schrieb Eric Schulte: This can be done system wide by setting the language-specific header arguments. I've yet to see an example on how to do this. #+begin_src emacs-lisp (setq org-babel-default-header-args:R '((:session . org-R))) #+end_src OK - that I see how this works. Although I would very much like to have a syntax to define this default language header as #+PROPERTY as it would be more consistent. But I remember there was a way of executing this code when opening but I can't find it anymore. #+RESULTS: | (:session . org-R) | #+begin_src R x - 1 x #+end_src #+RESULTS: : 1 #+begin_src R x #+end_src #+RESULTS: : 1 This can also be done file-wide through the use of file local variables (instead of the property line above). Still, language specific properties should exists. If you mean that there should be new syntax for setting header arguments on a file or sub-tree basis w/o using file local variables, I'd be happy to apply a patch. But importantly, there should be no way to set a default session name without also specifying the language, regardless of which way one tries to set this up. I think that would be a very important and useful aspect to include. If you can think of a clean way to implement this then we should go for Just an idea: if one would add a second value to the :session argument, one could use that one th specify the language for the session. If none is given, it would apply to all languages (so nothing changes), but if one is given, it would only apply to this language: #+PROPERTY: :session R-test R #+PROPERTY: :session none would set the language specific header :session to R-test, and the old session argument to none, it. I doubt many existing configurations rely on this behavior. If implemented as above, the default behavior would not be changed, so no changes need to be done by the user. In addition, this could be extended to other language specific headers (the only problem could be header arguments which take anyway multiple arguments, like :results). Cheers, Rainer Please read through the header argument documentation to see the many different ways in which header arguments may be set. http://orgmode.org/manual/Using-header-arguments.html This sends you off to Worg (which tries to send you back to where you came from), Clearly this portion of the manual should be improved. where you'll learn that there are no language specific header arguments for R and no further documentation on how to set defaults specific to R can easily be found (if it exists). Every language can specify default header arguments through setting a defvar. The syntax is `org-babel-default-header-args:lang'. This should not be hard to find through apropos, simple tab completion or searching the archives of this mailing list. However I agree the manual should be improved wrt this topic. Best, 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRUqd0AAoJENvXNx4PUvmC/HAIAJhoWFi8/D84V0FKNw1Y7TOW /7BXZHB8sDZENdO+35lqjJuKEKECcjSiwQOpa8KPffI4QYIJlsQzEbMSbTgl2+3H CaVARcnuj1hil0J7+EjTfWewbulCMSIDr9GsVpwMVKxl5VxY52/SRtOXyl7Ci2Td yAKDaPshq6kV15FdRF8MF30XxoEt+IH4p/u6m71Iq8poI8E8rqWhPufgeOdvhuNR q6yz57L0FG2kww//Mv3VByDvTf94+gbcMMtZ8qbrl+z3Mk+6I9WYTb6lzl3qP6je zW58K7rzorl8ZbbNe7GCmv0OOrEXXkkwHI5Ji00Jb+JMyBOrxe1r8cssHkFUbTo= =uNE3 -END PGP SIGNATURE-
Re: [O] :session question
Am 26.03.2013 13:37, schrieb Eric Schulte: Question from here: I use mainly R and have there set file wide #+PROPERTY: session R-session But I also have bash code, which would be evaluated in the R session, unless I use #+begin_src sh :session sh-session ... #+end_src But I do not need a session for the bash code blocks - so would :session none disable session for this source block? This would be great! Yes maybe just :session no rather than :session none Booleans written as strings reads terribly for me :( Cheers, Andreas
Re: [O] :session question - header argument setting
Hi Rainer, Rainer M Krug wrote: #+begin_src emacs-lisp (setq org-babel-default-header-args:R '((:session . org-R))) #+end_src OK - that I see how this works. Although I would very much like to have a syntax to define this default language header as #+PROPERTY as it would be more consistent. But I remember there was a way of executing this code when opening but I can't find it anymore. File local variable? Best regards, Seb -- Sebastien Vauban
Re: [O] :session question
Am 26.03.2013 16:31, schrieb Eric Schulte: Achim Gratz strom...@nexgo.de writes: Am 26.03.2013 13:37, schrieb Eric Schulte: This can be done system wide by setting the language-specific header arguments. I've yet to see an example on how to do this. #+begin_src emacs-lisp (setq org-babel-default-header-args:R '((:session . org-R))) #+end_src #+RESULTS: | (:session . org-R) | #+begin_src R x - 1 x #+end_src #+RESULTS: : 1 #+begin_src R x #+end_src #+RESULTS: : 1 Hi, this looks very confusing for me. So, what is the purpose of a named session? Understood it being a name-space, whose values don't affect the other ones. What's in python-mode a dedicated shell. As it reads, it clutters even the global languages name space? Best, Andreas
Re: [O] :session question
Andreas Röhler andreas.roeh...@easy-emacs.de writes: Am 26.03.2013 16:31, schrieb Eric Schulte: Achim Gratz strom...@nexgo.de writes: Am 26.03.2013 13:37, schrieb Eric Schulte: This can be done system wide by setting the language-specific header arguments. I've yet to see an example on how to do this. #+begin_src emacs-lisp (setq org-babel-default-header-args:R '((:session . org-R))) #+end_src #+RESULTS: | (:session . org-R) | #+begin_src R x - 1 x #+end_src #+RESULTS: : 1 #+begin_src R x #+end_src #+RESULTS: : 1 Hi, this looks very confusing for me. So, what is the purpose of a named session? Understood it being a name-space, whose values don't affect the other ones. What's in python-mode a dedicated shell. I can't speak for python, but in R, every differently named session will run within its own R process. The cool thing is, that I can work on file_foo.org and file_bar.org simultaneously, when file_foo.org uses R-session *foo* and file_bar.org uses R-session *bar*. [...] Regards, Andreas
Re: [O] :session question
Hi Eric, [...] #+begin_src emacs-lisp (setq org-babel-default-header-args:R '((:session . org-R))) #+end_src thanks a lot for this. I've looked for that option for such a long time, but simply did not find it. Now I have an emacs question: How would I use that in file-local-variables? The colon seems to cause trouble: # Local Variables: # org-babel-default-header-args:R: (quote ((:session . org-R))) # End: Thanks in advance for pointers. [...] Regards, Andreas
Re: [O] :session question
Am 27.03.2013 10:27, schrieb Andreas Leha: Andreas Röhler andreas.roeh...@easy-emacs.de writes: Am 26.03.2013 16:31, schrieb Eric Schulte: Achim Gratz strom...@nexgo.de writes: Am 26.03.2013 13:37, schrieb Eric Schulte: This can be done system wide by setting the language-specific header arguments. I've yet to see an example on how to do this. #+begin_src emacs-lisp (setq org-babel-default-header-args:R '((:session . org-R))) #+end_src #+RESULTS: | (:session . org-R) | #+begin_src R x - 1 x #+end_src #+RESULTS: : 1 #+begin_src R x #+end_src #+RESULTS: : 1 Hi, this looks very confusing for me. So, what is the purpose of a named session? Understood it being a name-space, whose values don't affect the other ones. What's in python-mode a dedicated shell. I can't speak for python, but in R, every differently named session will run within its own R process. The cool thing is, that I can work on file_foo.org and file_bar.org simultaneously, when file_foo.org uses R-session *foo* and file_bar.org uses R-session *bar*. [...] Regards, Andreas Okay, that's the expected usage. How do you read the example displayed? Looks like a named (:session . org-R) affects global R namespace. What did org-R say here, what might be the purpose? Assume it should switch it on. Then org-R represents a boolean here? Best, Andreas
Re: [O] :session question
Andreas Röhler andreas.roeh...@easy-emacs.de wrote: Am 27.03.2013 10:27, schrieb Andreas Leha: Andreas Röhler andreas.roeh...@easy-emacs.de writes: Am 26.03.2013 16:31, schrieb Eric Schulte: Achim Gratz strom...@nexgo.de writes: Am 26.03.2013 13:37, schrieb Eric Schulte: This can be done system wide by setting the language-specific header arguments. I've yet to see an example on how to do this. #+begin_src emacs-lisp (setq org-babel-default-header-args:R '((:session . org-R))) #+end_src #+RESULTS: | (:session . org-R) | #+begin_src R x - 1 x #+end_src #+RESULTS: : 1 #+begin_src R x #+end_src #+RESULTS: : 1 Hi, this looks very confusing for me. So, what is the purpose of a named session? Understood it being a name-space, whose values don't affect the other ones. What's in python-mode a dedicated shell. I can't speak for python, but in R, every differently named session will run within its own R process. The cool thing is, that I can work on file_foo.org and file_bar.org simultaneously, when file_foo.org uses R-session *foo* and file_bar.org uses R-session *bar*. [...] Regards, Andreas Okay, that's the expected usage. How do you read the example displayed? Looks like a named (:session . org-R) affects global R namespace. What did org-R say here, what might be the purpose? Assume it should switch it on. Then org-R represents a boolean here? org-R is the name of the session. The code blocks illustrate that the value of x (set in the first code block) is preserved and can be used in the second (and subsequent) code blocks. Nick
Re: [O] :session question
Am 27.03.2013 12:48, schrieb Nick Dokos: Andreas Röhler andreas.roeh...@easy-emacs.de wrote: Am 27.03.2013 10:27, schrieb Andreas Leha: Andreas Röhler andreas.roeh...@easy-emacs.de writes: Am 26.03.2013 16:31, schrieb Eric Schulte: Achim Gratz strom...@nexgo.de writes: Am 26.03.2013 13:37, schrieb Eric Schulte: This can be done system wide by setting the language-specific header arguments. I've yet to see an example on how to do this. #+begin_src emacs-lisp (setq org-babel-default-header-args:R '((:session . org-R))) #+end_src #+RESULTS: | (:session . org-R) | #+begin_src R x - 1 x #+end_src #+RESULTS: : 1 #+begin_src R x #+end_src #+RESULTS: : 1 Hi, this looks very confusing for me. So, what is the purpose of a named session? Understood it being a name-space, whose values don't affect the other ones. What's in python-mode a dedicated shell. I can't speak for python, but in R, every differently named session will run within its own R process. The cool thing is, that I can work on file_foo.org and file_bar.org simultaneously, when file_foo.org uses R-session *foo* and file_bar.org uses R-session *bar*. [...] Regards, Andreas Okay, that's the expected usage. How do you read the example displayed? Looks like a named (:session . org-R) affects global R namespace. What did org-R say here, what might be the purpose? Assume it should switch it on. Then org-R represents a boolean here? org-R is the name of the session. The code blocks illustrate that the value of x (set in the first code block) is preserved and can be used in the second (and subsequent) code blocks. Nick Okay, so the :session argument must not be repeated? i.e. doesn't look like a session, resp. not a named session #+begin_src R x - 1 x #+end_src Once a named session org-R is started all non-sessioned source goes there? Looks like a broken namespace.
Re: [O] :session question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27/03/13 13:18, Andreas Röhler wrote: Am 27.03.2013 12:48, schrieb Nick Dokos: Andreas Röhler andreas.roeh...@easy-emacs.de wrote: Am 27.03.2013 10:27, schrieb Andreas Leha: Andreas Röhler andreas.roeh...@easy-emacs.de writes: Am 26.03.2013 16:31, schrieb Eric Schulte: Achim Gratz strom...@nexgo.de writes: Am 26.03.2013 13:37, schrieb Eric Schulte: This can be done system wide by setting the language-specific header arguments. I've yet to see an example on how to do this. #+begin_src emacs-lisp (setq org-babel-default-header-args:R '((:session . org-R))) #+end_src #+RESULTS: | (:session . org-R) | #+begin_src R x - 1 x #+end_src #+RESULTS: : 1 #+begin_src R x #+end_src #+RESULTS: : 1 Hi, this looks very confusing for me. So, what is the purpose of a named session? Understood it being a name-space, whose values don't affect the other ones. What's in python-mode a dedicated shell. I can't speak for python, but in R, every differently named session will run within its own R process. The cool thing is, that I can work on file_foo.org and file_bar.org simultaneously, when file_foo.org uses R-session *foo* and file_bar.org uses R-session *bar*. [...] Regards, Andreas Okay, that's the expected usage. How do you read the example displayed? Looks like a named (:session . org-R) affects global R namespace. What did org-R say here, what might be the purpose? Assume it should switch it on. Then org-R represents a boolean here? org-R is the name of the session. The code blocks illustrate that the value of x (set in the first code block) is preserved and can be used in the second (and subsequent) code blocks. Nick Okay, so the :session argument must not be repeated? i.e. doesn't look like a session, resp. not a named session #+begin_src R x - 1 x #+end_src Once a named session org-R is started all non-sessioned source goes there? Looks like a broken namespace. Isn't it the same with all header arguments? when they are set file wide, they are used for the source block unless specified otherwise. 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRUuSDAAoJENvXNx4PUvmC2gEH/1t3vVle7zsa6tVYCMru5QEa uKr1o8+COJ8H92U28kn0++g4Qvtpu9cA8SRG8pH4bDw1Cv3kpg32CkQraJ6k7lIT gFTc1pcw33znfNwYJ4eHVz3uff5pXZOYBgJVtiYdmOEXMh1Kvg5UmHAB9mjoZC6L McZDRGCEGgjIkiGnrsZigCx3PEpYDTTMJ+qMDyaBA7csHxDXW96p3zUbFvLfWsaw 6egmMkvLca/WfJ1xjM4nbdp2VsPl/GofLWa/65hpGv5iMmOf/ixInhT2cQDsCmcB HukzR7Mu6BK4tHy6VGBOzRJARpo2fGGcMPv5BKRw6QRb3FhK/uBTLR6THt6FzFo= =z/jU -END PGP SIGNATURE-
Re: [O] :session question
org-R is the name of the session. The code blocks illustrate that the value of x (set in the first code block) is preserved and can be used in the second (and subsequent) code blocks. Nick Okay, so the :session argument must not be repeated? No one has said or implied that. i.e. doesn't look like a session, resp. not a named session The example below is from my previous email in which I demonstrated how to add a particular named session to the default header arguments list. Explicitly making that particular session global. As a side note, if one wants to set these R defaults for a single file the following syntax at the top of the file will suffice. # -*- org-babel-default-header-args:R: ((:session . foo)) -*- #+begin_src R x - 1 x #+end_src Once a named session org-R is started all non-sessioned source goes there? Looks like a broken namespace. Of course not. Trivial local experimentation could show that is not the case. Please actually try to run things locally before assuming that there are non-sensical bugs and posting questions to the mailing list. I don't think this line makes sense. If you can spend 10 more minutes writing an email to save the average reader one minute, please do so, as on average many more than 10 people will read every post you send to this list. Thanks, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] :session question
Am 27.03.2013 13:22, schrieb Rainer M Krug: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27/03/13 13:18, Andreas Röhler wrote: Am 27.03.2013 12:48, schrieb Nick Dokos: Andreas Röhler andreas.roeh...@easy-emacs.de wrote: Am 27.03.2013 10:27, schrieb Andreas Leha: Andreas Röhler andreas.roeh...@easy-emacs.de writes: Am 26.03.2013 16:31, schrieb Eric Schulte: Achim Gratz strom...@nexgo.de writes: Am 26.03.2013 13:37, schrieb Eric Schulte: This can be done system wide by setting the language-specific header arguments. I've yet to see an example on how to do this. #+begin_src emacs-lisp (setq org-babel-default-header-args:R '((:session . org-R))) #+end_src #+RESULTS: | (:session . org-R) | #+begin_src R x - 1 x #+end_src #+RESULTS: : 1 #+begin_src R x #+end_src #+RESULTS: : 1 [ ... ] Okay, that's the expected usage. How do you read the example displayed? Looks like a named (:session . org-R) affects global R namespace. What did org-R say here, what might be the purpose? Assume it should switch it on. Then org-R represents a boolean here? org-R is the name of the session. The code blocks illustrate that the value of x (set in the first code block) is preserved and can be used in the second (and subsequent) code blocks. Nick Okay, so the :session argument must not be repeated? i.e. doesn't look like a session, resp. not a named session #+begin_src R x - 1 x #+end_src Once a named session org-R is started all non-sessioned source goes there? Looks like a broken namespace. Isn't it the same with all header arguments? when they are set file wide, they are used for the source block unless specified otherwise. Rainer Hmm, may you point me to the file-wide setting? Form at stake (setq org-babel-default-header-args:R '((:session . org-R))) seems to put all remaining R-evaluations into a named session org-R Don't see any restriction onto a file resp. buffer. Maybe that's thought implicit? Thanks, Andreas
Re: [O] :session question
Am 27.03.2013 13:43, schrieb Eric Schulte: org-R is the name of the session. The code blocks illustrate that the value of x (set in the first code block) is preserved and can be used in the second (and subsequent) code blocks. Nick Okay, so the :session argument must not be repeated? No one has said or implied that. Looks for me as this code from your example runs in session mode without explicit :session argument given: #+begin_src R x - 1 x #+end_src #+RESULTS: : 1 #+begin_src R x #+end_src #+RESULTS: : 1 [ ... ]
Re: [O] :session question
Hi Eric, [...] As a side note, if one wants to set these R defaults for a single file the following syntax at the top of the file will suffice. # -*- org-babel-default-header-args:R: ((:session . foo)) -*- That does not work for me. (I am on GNU Emacs 24.3.50.1, org-mode version 8.0-pre (release_8.0-pre-97-gffdd9e)) When I open an org-file containing that line, I get , | Malformed mode-line ` and have to answer , | The local variables list contains values that may not be safe(*). | | (*) org-babel-default-header-args : R: | | Please type y, n, or !: y ` When I accept and try to actually evaluate R-code, I get , | Wrong type argument: sequencep, R: | ` What am I missing? Regards, Andreas
Re: [O] :session question
Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi Eric, [...] As a side note, if one wants to set these R defaults for a single file the following syntax at the top of the file will suffice. # -*- org-babel-default-header-args:R: ((:session . foo)) -*- That does not work for me. (I am on GNU Emacs 24.3.50.1, org-mode version 8.0-pre (release_8.0-pre-97-gffdd9e)) That's weird, it works perfectly for me. I'm using the same version of Emacs, but an earlier version of Org-mode. Org-mode version 7.9.3f (release_7.9.3f-17-g7524ef @ /usr/share/emacs/24.3/lisp/org/) When I open an org-file containing that line, I get , | Malformed mode-line ` and have to answer , | The local variables list contains values that may not be safe(*). | | (*) org-babel-default-header-args : R: | | Please type y, n, or !: y ` When I accept and try to actually evaluate R-code, I get , | Wrong type argument: sequencep, R: | ` What am I missing? I'm not sure. For some reason Emacs thinks the variable ends at the : in the variable name. I'm attaching the complete example file I've used locally, please retry with that and see if the problem persists. # -*- org-babel-default-header-args:R: ((:session . foo)) -*- #+Title: Example #+Author: Eric Schulte For more information on file local variables see [[info:elisp#File%20Local%20Variables][info:elisp#File Local Variables]]. Because there is a default :session values assigned locally for R blocks we have the following. #+begin_src R x - 1 x #+end_src #+RESULTS: : 1 #+begin_src R x #+end_src #+RESULTS: : 1 But non-R code blocks do not have a default session value. #+begin_src sh date #+end_src #+RESULTS: : Wed Mar 27 09:45:47 MDT 2013 Best, Regards, Andreas -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] :session question
Hi Eric, Eric Schulte schulte.e...@gmail.com writes: Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi Eric, [...] As a side note, if one wants to set these R defaults for a single file the following syntax at the top of the file will suffice. # -*- org-babel-default-header-args:R: ((:session . foo)) -*- That does not work for me. (I am on GNU Emacs 24.3.50.1, org-mode version 8.0-pre (release_8.0-pre-97-gffdd9e)) That's weird, it works perfectly for me. I'm using the same version of Emacs, but an earlier version of Org-mode. Org-mode version 7.9.3f (release_7.9.3f-17-g7524ef @ /usr/share/emacs/24.3/lisp/org/) When I open an org-file containing that line, I get , | Malformed mode-line ` and have to answer , | The local variables list contains values that may not be safe(*). | | (*) org-babel-default-header-args : R: | | Please type y, n, or !: y ` When I accept and try to actually evaluate R-code, I get , | Wrong type argument: sequencep, R: | ` What am I missing? I'm not sure. For some reason Emacs thinks the variable ends at the : in the variable name. I'm attaching the complete example file I've used locally, please retry with that and see if the problem persists. # -*- org-babel-default-header-args:R: ((:session . foo)) -*- #+Title: Example #+Author: Eric Schulte For more information on file local variables see [[info:elisp#File%20Local%20Variables][info:elisp#File Local Variables]]. Because there is a default :session values assigned locally for R blocks we have the following. #+begin_src R x - 1 x #+end_src #+RESULTS: : 1 #+begin_src R x #+end_src #+RESULTS: : 1 But non-R code blocks do not have a default session value. #+begin_src sh date #+end_src #+RESULTS: : Wed Mar 27 09:45:47 MDT 2013 Thanks for your answer! I tested with your file. I only get the 'Malformed mode-line'. (The questions about unsave variables was my mistake.) But the session 'foo' is still not started, but the code blocks are evaluated as if there was no session specified: #+begin_org # -*- org-babel-default-header-args:R: ((:session . foo)) -*- #+Title: Example #+Author: Eric Schulte For more information on file local variables see [[info:elisp#File%20Local%20Variables][info:elisp#File Local Variables]]. Because there is a default :session values assigned locally for R blocks we have the following. #+begin_src R x - 1 x #+end_src #+RESULTS: : 1 #+begin_src R x #+end_src #+RESULTS: But non-R code blocks do not have a default session value. #+begin_src sh date #+end_src #+RESULTS: : Mi 27. Mär 21:18:49 CET 2013 #+end_org Is that just not working for me? And any ideas, what I could do about it? Regards, Andreas
Re: [O] :session question
Andreas Leha andreas.l...@med.uni-goettingen.de writes: [...] Is that just not working for me? And any ideas, what I could do about it? I have no good ideas. Is the `org-babel-default-header-args:R' variable defined on your system before you load this file? If not, maybe you should be sure to add (require 'ob-R) to your emacs initialization. If the : in the variable name is somehow confusing your Emacs, then possibly you could use the alternate format of specifying file local variables (see the info link in my attached example). I hope one of these works, aside from that I have no idea why our Emacs versions would differ in such fundamental behavior. Cheers, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] :session question
[ ... ] But non-R code blocks do not have a default session value. #+begin_src sh date #+end_src #+RESULTS: : Mi 27. Mär 21:18:49 CET 2013 #+end_org Would say rather: global defaults are not predictable from users perspective, as global :seesion settings may have an effect or not. See in Common Lisp for example, which is always in session-mode IIUC
Re: [O] :session question
Am 26.03.2013 00:58, schrieb Michael Gauland: Andreas Röhler andreas.roehler at easy-emacs.de writes: Would find it more natural if :session is the default, while a command refresh makes a new one. I don't think so, but perhaps I'm just used to the way it works now. I use a mix of session and non-session blocks. When I use plantuml, dot, or asymptote to generate images, I don't use sessions (I'm not sure these languages even support sessions). Which is a strong argument for the present explicit way. Otherwise it would be hard to detect if results are kept or not. Thanks, Andreas I almost always use sessions for R, because I want to use the same data in different blocks. I also generally use sessions for Racket (scheme), even when I don't to share data across blocks, so I don't need to wait for the interpreter to start up for each block. Kind Regards, Mike Gauland
Re: [O] :session question
Thanks! Am 26.03.2013 01:46, schrieb Eric Schulte: Michael Gauland mikely...@no8wireless.co.nz writes: Andreas Röhler andreas.roehler at easy-emacs.de writes: Would find it more natural if :session is the default, while a command refresh makes a new one. Header argument defaults are easy to accomplish on a per user or per file basis, just customize the `org-babel-default-header-args' variable. ,[org-babel-default-header-args] | org-babel-default-header-args is a variable defined in `ob.el'. | Its value is ((:noweb . yes) | (:session . none) | (:results . replace) | (:exports . code) | (:cache . no) | (:hlines . no) | (:tangle . no) | (:padnewline . yes)) | | | Documentation: | Default arguments to use when evaluating a source block. | | [back] `
Re: [O] :session question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/03/13 01:46, Eric Schulte wrote: Michael Gauland mikely...@no8wireless.co.nz writes: Andreas Röhler andreas.roehler at easy-emacs.de writes: Would find it more natural if :session is the default, while a command refresh makes a new one. Header argument defaults are easy to accomplish on a per user or per file basis, just customize the `org-babel-default-header-args' variable. ,[org-babel-default-header-args] | org-babel-default-header-args is a variable defined in `ob.el'. | Its value is ((:noweb . yes) | (:session . none) | (:results . replace) | (:exports . code) | (:cache . no) | (:hlines . no) | (:tangle . no) | (:padnewline . yes)) | | | Documentation: | Default arguments to use when evaluating a source block. Question from here: I use mainly R and have there set file wide #+PROPERTY: session R-session But I also have bash code, which would be evaluated in the R session, unless I use #+begin_src sh :session sh-session ... #+end_src But I do not need a session for the bash code blocks - so would :session none disable session for this source block? This would be great! Also: it would be quite nice if one could set the session argument specific for languages, so that I could file wide #+PROPERTY: R-session R #+PROPERTY: sh-session sh but the default for all un-specified languages would be no sessio use. Is there a possibility to do it? Cheers, Rainer | | [back] ` - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRUWaZAAoJENvXNx4PUvmCdEYH/RBXokBJsbPp9bFK/9IRv5k9 xxpkTClUlUBgfKOjQIDCUxkQ53iyuhdGXkM5d9CNXi0VrOEU8lAsEKscyJBaDEMY 6bcfT6TgULw53uOL42dpwfh+dw/URyCyCI4TY+IazRQ80eR4GZVcTNNSKwwjoZmJ b5PUFX1f5qtiS4oxC91GqBWujLSDrQS0sLMOUG7UYXTv2UJNTKWphyw7srdXakA+ A7fvl4lEnpX2sXbi8YJCvmICW1k3L1KcMkM1RSx2TbOLFxfEbc2mHQew6UganHG2 Ww+DeBqT197TJ7sUF6vMPAIs4r7Hu/Nwm7jsYdANFe6QgKHVbCvsv+SRSV4v5nY= =ei0N -END PGP SIGNATURE-
Re: [O] :session question
Rainer M Krug r.m.k...@gmail.com writes: On 26/03/13 01:46, Eric Schulte wrote: Michael Gauland mikely...@no8wireless.co.nz writes: Andreas Röhler andreas.roehler at easy-emacs.de writes: Would find it more natural if :session is the default, while a command refresh makes a new one. Header argument defaults are easy to accomplish on a per user or per file basis, just customize the `org-babel-default-header-args' variable. ,[org-babel-default-header-args] | org-babel-default-header-args is a variable defined in `ob.el'. | Its value is ((:noweb . yes) | (:session . none) | (:results . replace) | (:exports . code) | (:cache . no) | (:hlines . no) | (:tangle . no) | (:padnewline . yes)) | | | Documentation: | Default arguments to use when evaluating a source block. Question from here: I use mainly R and have there set file wide #+PROPERTY: session R-session But I also have bash code, which would be evaluated in the R session, unless I use #+begin_src sh :session sh-session ... #+end_src But I do not need a session for the bash code blocks - so would :session none disable session for this source block? This would be great! Also: it would be quite nice if one could set the session argument specific for languages, so that I could file wide #+PROPERTY: R-session R #+PROPERTY: sh-session sh +1 [...] Regards, Andreas
Re: [O] :session question
Hi Eric, Eric Schulte schulte.e...@gmail.com writes: Question from here: I use mainly R and have there set file wide #+PROPERTY: session R-session But I also have bash code, which would be evaluated in the R session, unless I use #+begin_src sh :session sh-session ... #+end_src But I do not need a session for the bash code blocks - so would :session none disable session for this source block? This would be great! Yes Also: it would be quite nice if one could set the session argument specific for languages, so that I could file wide #+PROPERTY: R-session R #+PROPERTY: sh-session sh +1 This can be done system wide by setting the language-specific header arguments. This can also be done file-wide through the use of file local variables (instead of the property line above). Please read through the header argument documentation to see the many different ways in which header arguments may be set. http://orgmode.org/manual/Using-header-arguments.html Best, Thanks for taking this up. And sorry for my ignorance. I have read the linked pages, but I still do not know how to achieve the language specific session values. Could you provide an example? Regards, Andreas
Re: [O] :session question
Am 26.03.2013 13:37, schrieb Eric Schulte: This can be done system wide by setting the language-specific header arguments. I've yet to see an example on how to do this. This can also be done file-wide through the use of file local variables (instead of the property line above). Still, language specific properties should exists. But importantly, there should be no way to set a default session name without also specifying the language, regardless of which way one tries to set this up. Please read through the header argument documentation to see the many different ways in which header arguments may be set. http://orgmode.org/manual/Using-header-arguments.html This sends you off to Worg (which tries to send you back to where you came from), where you'll learn that there are no language specific header arguments for R and no further documentation on how to set defaults specific to R can easily be found (if it exists). Regards, -- Achim. (on the road :-)
Re: [O] :session question
Achim Gratz strom...@nexgo.de writes: Am 26.03.2013 13:37, schrieb Eric Schulte: This can be done system wide by setting the language-specific header arguments. I've yet to see an example on how to do this. #+begin_src emacs-lisp (setq org-babel-default-header-args:R '((:session . org-R))) #+end_src #+RESULTS: | (:session . org-R) | #+begin_src R x - 1 x #+end_src #+RESULTS: : 1 #+begin_src R x #+end_src #+RESULTS: : 1 This can also be done file-wide through the use of file local variables (instead of the property line above). Still, language specific properties should exists. If you mean that there should be new syntax for setting header arguments on a file or sub-tree basis w/o using file local variables, I'd be happy to apply a patch. But importantly, there should be no way to set a default session name without also specifying the language, regardless of which way one tries to set this up. If you can think of a clean way to implement this then we should go for it. I doubt many existing configurations rely on this behavior. Please read through the header argument documentation to see the many different ways in which header arguments may be set. http://orgmode.org/manual/Using-header-arguments.html This sends you off to Worg (which tries to send you back to where you came from), Clearly this portion of the manual should be improved. where you'll learn that there are no language specific header arguments for R and no further documentation on how to set defaults specific to R can easily be found (if it exists). Every language can specify default header arguments through setting a defvar. The syntax is `org-babel-default-header-args:lang'. This should not be hard to find through apropos, simple tab completion or searching the archives of this mailing list. However I agree the manual should be improved wrt this topic. Best, Regards, -- Eric Schulte http://cs.unm.edu/~eschulte
[O] :session question
Hi all, org-babel uses the header argument :session keeping the environment for consecutive evaluations. That feels the opposite of all on-the-fly evaluations commonly done by a (language)-shell. Commonly a shell keeps is values until a new one is created. Would find it more natural if :session is the default, while a command refresh makes a new one. Also instead of :session a header argument :dedicated would provide a new process every time. As we have a bug around, maybe it's a good moment to consider that, Andreas
Re: [O] :session question
Andreas Röhler andreas.roehler at easy-emacs.de writes: Would find it more natural if :session is the default, while a command refresh makes a new one. I don't think so, but perhaps I'm just used to the way it works now. I use a mix of session and non-session blocks. When I use plantuml, dot, or asymptote to generate images, I don't use sessions (I'm not sure these languages even support sessions). I almost always use sessions for R, because I want to use the same data in different blocks. I also generally use sessions for Racket (scheme), even when I don't to share data across blocks, so I don't need to wait for the interpreter to start up for each block. Kind Regards, Mike Gauland
Re: [O] :session question
Michael Gauland mikely...@no8wireless.co.nz writes: Andreas Röhler andreas.roehler at easy-emacs.de writes: Would find it more natural if :session is the default, while a command refresh makes a new one. Header argument defaults are easy to accomplish on a per user or per file basis, just customize the `org-babel-default-header-args' variable. ,[org-babel-default-header-args] | org-babel-default-header-args is a variable defined in `ob.el'. | Its value is ((:noweb . yes) | (:session . none) | (:results . replace) | (:exports . code) | (:cache . no) | (:hlines . no) | (:tangle . no) | (:padnewline . yes)) | | | Documentation: | Default arguments to use when evaluating a source block. | | [back] ` -- Eric Schulte http://cs.unm.edu/~eschulte
