Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Eric: Thanks - but for the moment I will go with Jambunathan's suggestion and stick with the latest version before the removal of BABEL. For the record, I created a local branch before the removal of BABEL and used git checkout MyBranch to switch to this branch. So I can keep my local git repo up-to-date and switch back to master if I want to. Cheers, Rainer On Thu, Nov 3, 2011 at 7:51 PM, Jambunathan K kjambunat...@gmail.comwrote: Rainer - if he feels uncomfortable - can choose *not* to update his git repo and switch his local checkout to a historical version. [1] to see the info page evaluate (info (elisp)File Local Variables) A usage note for adding these variables without straining the brain. M-x add-file-local-variable RET M-x add-file-local-variable-prop-line RET These commands are documented here. (info (emacs) Specifying File Variables) -- -- 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 (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
In order to prevent confusion or needless argument: the path I think we should back off of is the committing of these changes to master - I think the work should be done in a branch and cooked thoroughly before merging it to master. Partly agree here - I was bitten by the changes, and have suspended work on one project until this issue stabilizes - I do not want to change my files after each change. Hi Rainer, In a previous thread in which you were included I suggested a solution which works now and will continue to work in the future no matter how this issue is resolved. That solution is to use a multi-line file local variable [1] to customize the org-babel-default-header-args variable. I should have made a bigger deal of this solution when I posted it the first time, my apologies. In general I think we do a good job of not breaking functionality without on this master branch, and I think that introducing a multitude of branches would only serve to add confusion, reduce org-wide cooperation, and ultimately only delay rather than somehow remove them. Best -- Eric Footnotes: [1] to see the info page evaluate (info (elisp)File Local Variables) -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Rainer - if he feels uncomfortable - can choose *not* to update his git repo and switch his local checkout to a historical version. [1] to see the info page evaluate (info (elisp)File Local Variables) A usage note for adding these variables without straining the brain. M-x add-file-local-variable RET M-x add-file-local-variable-prop-line RET These commands are documented here. (info (emacs) Specifying File Variables) --
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On Tue, Nov 1, 2011 at 4:17 PM, Eric Schulte schulte.e...@gmail.com wrote: Nick Dokos nicholas.do...@hp.com writes: Nick Dokos nicholas.do...@hp.com wrote: Can we please back off this path? In order to prevent confusion or needless argument: the path I think we should back off of is the committing of these changes to master - I think the work should be done in a branch and cooked thoroughly before merging it to master. Partly agree here - I was bitten by the changes, and have suspended work on one project until this issue stabilizes - I do not want to change my files after each change. I would agree that these changes should be happening in branches if the problems were technical, however the issues that need to be addressed are social issues of consensus, and for better or worse pushing changes to the master branch is the best way to alert all interested actors and begin the consensus-building process. If these changes had been pushed up to a branch they would be sitting happily in that branch with no-one noticing or objecting. They had been discussed at length on list before their implementation and commitance, but this most recent round of discussion was caused by a push to the master branch. You are definitely right about that - but it is kind of forcing the issue on to users after telling them they should use git as org is very dynamic, which is a risky business, as it might put users of - consider a new org user who realizes that regularly things are changing which affect him, and he / she has to change aspects of their org files. I would say it is a double edged sword. This is also after all the development repository, and while I do try very hard never to break this head of this repository at the same time I think it is an acceptable place to try out new functionality. Again - true, but it is always recommended on the org-list to use the git repo, as it contains all bug fixes. I did not mean to imply (although I think one could easily get that impression from my mail) backing off the property implementation (despite my personal reservations about that). OK, good, because I *do* think that properties are a natural fit for specifying code block parameters. The use of subtree properties has already proven itself, and file-wide properties are a natural extension (much more natural than the introduction of a #+BABEL: header argument). Then one should possibly also think of merging #+LATEX into #+PROPERTY - which I think would make it more consistent (and this is a serious suggestion). So: all file-wide properties, #+PROPERTIES is used. What would be really important, is to have one page on worg, on which this process is documented - i.e. how files need to be changed, to be used with which version of org. I definitely have no idea, how I have to modify my files at the moment (there was the discussion abour source_name, name, ... and then the #+PROPERTY - I hope I haven't missed anything?). As I said - I have the luck, that I can wait until it stabilizes (at least I hope) - but a regularly updated summary with changes would be very welcome (and I guess I can speak for many org users). Even if this step is painful for many (especially the ones not to familiar with the inner workings of org and babel (this definitely includes me)), I am sure that the best solution will be found (hopefully soon) and we will have a better and stronger org-mode at hand. Cheers, Rainer While there is certainly some pain in this process I think it is nailing down both the needs for code block properties as well as the scope of what is and is not desirable functionality for properties in general. Best -- Eric Nick -- Eric Schulte http://cs.unm.edu/~eschulte/ -- 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 (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hello, Rainer M Krug r.m.k...@gmail.com writes: Then one should possibly also think of merging #+LATEX into #+PROPERTY - which I think would make it more consistent (and this is a serious suggestion). Are you sure you're talking about the #+LATEX: keywords, allowing to insert LaTeX code only for the LaTeX exporter? If that's the case, I fail to see your point. So: all file-wide properties, #+PROPERTIES is used. #+PROPERTIES: isn't really about file-wide properties, but only about properties applying to each headline in the buffer. It's a generalization of the property drawers. That's quite different, actually. For example, #+TITLE: is a file-wide property that doesn't belong to #+PROPERTIES:. In other words, a property should belong to #+PROPERTIES if it may have different values for different sections. Regards, -- Nicolas Goaziou
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On Tue, Nov 1, 2011 at 10:17 AM, Eric Schulte schulte.e...@gmail.com wrote: This is also after all the development repository, and while I do try very hard never to break this head of this repository at the same time I think it is an acceptable place to try out new functionality. Given that a common recommendation for a bug fix is to 'try commit blah blah blah', would it make sense to have bug fixes go onto a 'maint' branch (as well as master), and new features / changed features stay on the master branch? At the time when 'master' is ready for a new official release, it could then be merged into 'maint' to create the next stable point for bug fixes. Adding features on the same branch as bug fixes, when 'official releases' are not made frequently seems to be a formula for frustration. Thoughts? Brian
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On Wed, Nov 2, 2011 at 1:18 PM, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, Rainer M Krug r.m.k...@gmail.com writes: Then one should possibly also think of merging #+LATEX into #+PROPERTY - which I think would make it more consistent (and this is a serious suggestion). Are you sure you're talking about the #+LATEX: keywords, allowing to insert LaTeX code only for the LaTeX exporter? If that's the case, I fail to see your point. So: all file-wide properties, #+PROPERTIES is used. #+PROPERTIES: isn't really about file-wide properties, but only about properties applying to each headline in the buffer. It's a generalization of the property drawers. That's quite different, actually. For example, #+TITLE: is a file-wide property that doesn't belong to #+PROPERTIES:. In other words, a property should belong to #+PROPERTIES if it may have different values for different sections. I am now completely confused - but that is fine. I give up for now. Just one question: could you, Eric, please give a summary, as soon as the changes are fixed, on how I have to change my org-files so that they are working again? Thanks, Rainer Regards, -- Nicolas Goaziou -- 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 (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On Wed, Nov 2, 2011 at 1:57 PM, Brian Wightman midlife...@wightmanfam.orgwrote: On Tue, Nov 1, 2011 at 10:17 AM, Eric Schulte schulte.e...@gmail.com wrote: This is also after all the development repository, and while I do try very hard never to break this head of this repository at the same time I think it is an acceptable place to try out new functionality. Given that a common recommendation for a bug fix is to 'try commit blah blah blah', would it make sense to have bug fixes go onto a 'maint' branch (as well as master), and new features / changed features stay on the master branch? At the time when 'master' is ready for a new official release, it could then be merged into 'maint' to create the next stable point for bug fixes. Adding features on the same branch as bug fixes, when 'official releases' are not made frequently seems to be a formula for frustration. Added features are not that much of a problem, but changes which affect backward compatibility are. But there were not many in the past that I am aware of. Cheers, Rainer Thoughts? Brian -- 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 (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hi Brian, Brian Wightman midlife...@wightmanfam.org writes: Given that a common recommendation for a bug fix is to 'try commit blah blah blah', would it make sense to have bug fixes go onto a 'maint' branch (as well as master), and new features / changed features stay on the master branch? Yes, this makes sense, and this has already been suggested. The reason why I'm not using such a scheme is 1) pure laziness and 2) the fact that the current git scheme is good enough. But it might not be good enough for long, and perhaps future maintainers will not be as lazy as I am wrt this. Thanks for the suggestion, -- Bastien
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Eric Schulte schulte.e...@gmail.com wrote: My concerns with respect to a property drawer solution are two fold. 1) In the same way that #+PROPERTY: assumes its value will live on a single line, property drawers assume that their values will live on a single line. I don't see how it will be easier to fold multi-line properties into drawers than outside of drawers. 2) It is not possible to specify file-wide properties with drawers, unlike with property lines. Thanks -- Eric I felt uneasy about #+begin_property, but I could not articulate my unease until first Nicolas and then Samuel expressed some of their concerns. But it seemed to me from the beginning that properties were *not* the right fit for babel whole-file args and I'm more convinced than ever that this is the *wrong* direction: it conflates different concepts and it forces changes in a well established area in order to satisfy the concerns of the other area. Can we please back off this path? The changes are big, they affect users' everyday work and it is not clear where they are going to end up. Let's revert the changes to master, establish a branch, and do all this experimentation in a branch. When it is thoroughly cooked to most people's satisfaction, it can be merged into master. That way, people can continue their daily work, without having to worry about changing their files to satisfy the new changes. Git provided exceptionally flexible branching: let's use it. My two cents, Nick Samuel Wales samolog...@gmail.com writes: Hi Eric, Properties can be specified in the properties drawer. But multiple-line ones cannot at present (at least not without serializing the way multiple-line macros are serialized). Therefore you propose new syntax for multiple-line properties. I propose that allowing the properties drawer to handle multiple-line properties might have 3 advantages over adding block syntax. 1: If you want a single-line property, you have a choice. If you want a multiple-line property, you have to use a block. That seems inconsistent. 2: Some people would probably have use for multiple-line properties, such as in org-contacts. Doesn't have to be Babel. People are used to the properties drawer. Also, external parsers are. 3: Nic objects to blocks without discussing them first. Perhaps upgrading properties drawer will satisfy that objection /and/ be consistent /and/ allow further uses in Org. This all presumes we're sticking with properties for Babel. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com === Bigotry against people with serious diseases is still bigotry. -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Nick Dokos nicholas.do...@hp.com wrote: Can we please back off this path? In order to prevent confusion or needless argument: the path I think we should back off of is the committing of these changes to master - I think the work should be done in a branch and cooked thoroughly before merging it to master. I did not mean to imply (although I think one could easily get that impression from my mail) backing off the property implementation (despite my personal reservations about that). Nick
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Nick Dokos nicholas.do...@hp.com writes: Nick Dokos nicholas.do...@hp.com wrote: Can we please back off this path? In order to prevent confusion or needless argument: the path I think we should back off of is the committing of these changes to master - I think the work should be done in a branch and cooked thoroughly before merging it to master. I would agree that these changes should be happening in branches if the problems were technical, however the issues that need to be addressed are social issues of consensus, and for better or worse pushing changes to the master branch is the best way to alert all interested actors and begin the consensus-building process. If these changes had been pushed up to a branch they would be sitting happily in that branch with no-one noticing or objecting. They had been discussed at length on list before their implementation and commitance, but this most recent round of discussion was caused by a push to the master branch. This is also after all the development repository, and while I do try very hard never to break this head of this repository at the same time I think it is an acceptable place to try out new functionality. I did not mean to imply (although I think one could easily get that impression from my mail) backing off the property implementation (despite my personal reservations about that). OK, good, because I *do* think that properties are a natural fit for specifying code block parameters. The use of subtree properties has already proven itself, and file-wide properties are a natural extension (much more natural than the introduction of a #+BABEL: header argument). While there is certainly some pain in this process I think it is nailing down both the needs for code block properties as well as the scope of what is and is not desirable functionality for properties in general. Best -- Eric Nick -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
It is now possible to specify multi-line properties using a property block. This should make it more natural to specify many file-wide variables through properties. For example, #+begin_property var foo=1, bar=2, baz=3, qux=4 #+end_property #+begin_src emacs-lisp (+ foo bar baz qux) #+end_src #+results: : 10 Cheers -- Eric Darlan Cavalcante Moreira darc...@gmail.com writes: I didn't check the list for 3 days and this thread became a little hard to follow. So, forgive me if I'm answering the wrong E-Mail. I liked Christian's idea of using a single var property to tell babel which regular properties it should use as variables (ignoring any variable not defined). This would be enough for my use cases. On the other hand, some way to append values to a property, such as using some special keyword as I have suggested, could be a better solution in order to keep consistence if people want this feature for non-babel related properties. -- Darlan At Sat, 22 Oct 2011 09:53:25 -0600, Eric Schulte wrote: Darlan Cavalcante Moreira darc...@gmail.com writes: It's excellent that now babel understands multiple values in the var property (I was one of the people that wanted this), but There Is One More Thing. Would it be feasible to inherit variables from parent sub-trees? Effectively, I'd like to append new values in lower level sub-trees, but AFAIK setting the var property in a sub-tree will still replace the value set in the parent sub-tree. Currently every new property specification entirely replaced previous specifications with the same name. That is, in the example below the level-2 sub-trees would not have the foo variable passed to babel. * Code with foo :PROPERTIES: :var: foo=1 :END: ** Code only with bar :PROPERTIES: :var: bar=2 :END: src_block ** Code only with baz :PROPERTIES: :var: baz=3 :END: src_block Maybe a special keyword, such as inherit (or append) could be used to incorporate variables defined in the parent sub-tree, such that the example would become * Code with foo :PROPERTIES: :var: foo=1 :END: ** Code with foo and bar :PROPERTIES: :var: bar=2, inherit :END: src_block ** Code with foo and baz :PROPERTIES: :var: baz=3, inherit :END: src_block This should not affect global variables and inherit would inherit variables defined only in the parent sub-tree (unless it also contains the inherit keyword). As a use case scenario, suppose I need to perform simulations for a few different scenarios, each with small variations. This would allow me to define common variables for a scenario in a higher level sub-tree and more specific variables in the lower level sub-trees. This sounds somewhat similar to my suggestion in reply to Rainer's email. Best -- Eric -- Darlan Cavalcante At Fri, 21 Oct 2011 22:24:25 +0200, Christian Moe m...@christianmoe.com wrote: Hi, Yes, that works nicely, and should solve Rainer's problem. I haven't been able to think of anything else that can't be handled by properties. And I do think it's a good idea to winnow down the syntax a bit, even if things break. I just like to grumble. :-) Yours, Christian On 10/21/11 7:37 PM, Eric Schulte wrote: Nice idea. This same issue with var arose when we first started allowing header arguments to be specified inside subtree properties. I've just implemented your suggestion so the following are now possible. #+PROPERTY: var foo=1, bar=2 #+PROPERTY: cache yes #+begin_src emacs-lisp (+ foo bar) #+end_src #+results[be32e67491d4e92f75769aebe423c20ca01626fe]: : 3 and #+begin_src emacs-lisp :var foo=this, bar=that (concat foo bar) #+end_src #+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]: : this that Thanks for the suggestion and I hope the above is a sufficient replacement for the now-missing #+BABEL: syntax. Cheers -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/ -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On 2011-10-31, Eric Schulte schulte.e...@gmail.com wrote: It is now possible to specify multi-line properties using a property block. This should make it more natural to specify many file-wide variables through properties. For example, Could this be changed to work using the property drawer?
[O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hi Eric, Properties can be specified in the properties drawer. But multiple-line ones cannot at present (at least not without serializing the way multiple-line macros are serialized). Therefore you propose new syntax for multiple-line properties. I propose that allowing the properties drawer to handle multiple-line properties might have 3 advantages over adding block syntax. 1: If you want a single-line property, you have a choice. If you want a multiple-line property, you have to use a block. That seems inconsistent. 2: Some people would probably have use for multiple-line properties, such as in org-contacts. Doesn't have to be Babel. People are used to the properties drawer. Also, external parsers are. 3: Nic objects to blocks without discussing them first. Perhaps upgrading properties drawer will satisfy that objection /and/ be consistent /and/ allow further uses in Org. This all presumes we're sticking with properties for Babel. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com === Bigotry against people with serious diseases is still bigotry. -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com === Bigotry against people with serious diseases is still bigotry.
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
My concerns with respect to a property drawer solution are two fold. 1) In the same way that #+PROPERTY: assumes its value will live on a single line, property drawers assume that their values will live on a single line. I don't see how it will be easier to fold multi-line properties into drawers than outside of drawers. 2) It is not possible to specify file-wide properties with drawers, unlike with property lines. Thanks -- Eric Samuel Wales samolog...@gmail.com writes: Hi Eric, Properties can be specified in the properties drawer. But multiple-line ones cannot at present (at least not without serializing the way multiple-line macros are serialized). Therefore you propose new syntax for multiple-line properties. I propose that allowing the properties drawer to handle multiple-line properties might have 3 advantages over adding block syntax. 1: If you want a single-line property, you have a choice. If you want a multiple-line property, you have to use a block. That seems inconsistent. 2: Some people would probably have use for multiple-line properties, such as in org-contacts. Doesn't have to be Babel. People are used to the properties drawer. Also, external parsers are. 3: Nic objects to blocks without discussing them first. Perhaps upgrading properties drawer will satisfy that objection /and/ be consistent /and/ allow further uses in Org. This all presumes we're sticking with properties for Babel. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com === Bigotry against people with serious diseases is still bigotry. -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hi Eric, Eric Schulte wrote: I think that makes sense. While thinking about all of this, and working in real-life documents, I just came back to a suggestion which I made some time ago. It goes about this enhancement: Would it be possible to specify buffer-wide language specific header arguments? Yes, this is already possible. You can customize the org-babel-default-header-args:lang variable (where lang is the source name) as a file local variable. That is, be able to say: In this document, I want to: - tangle all my .sql chunks, but no other; - eval all the elisp chunks with query, but no other. Something we could write quite easily along the lines: #+PROPERTY: tangle no #+PROPERTY: eval never #+PROPERTY[SQL]: tangle yes #+PROPERTY[EMACS-LISP]: eval query (the syntax used here is just a draft sample!) I do not think we can customize the PROPERTY syntax as is exists outside of Babel. The goal here was to piggy-back on top of rather than co-opt regular Org-mode syntax. I understand that argument. It's just that the current solution is not optimal (among others) for documents mixing R and shell code: you don't want your session property to be common between both languages (shell code sent to your R terminal, or vice-versa). But it's nice this case is already handled in a more generic way than on the code blocks themselves, and I can live with that. Thanks again for your help. Best regards, Seb -- Sebastien Vauban
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Eric, Eric Schulte wrote: I think that makes sense. While thinking about all of this, and working in real-life documents, I just came back to a suggestion which I made some time ago. It goes about this enhancement: Would it be possible to specify buffer-wide language specific header arguments? Yes, this is already possible. You can customize the org-babel-default-header-args:lang variable (where lang is the source name) as a file local variable. Hi Seb, ^ | I just wanted to make sure you saw the above solution for specifying file-wide language-specific header arguments. Emacs' support for buffer local variables makes this fairly easy to implement. In fact buffer local variables could also be used to specify multi-langauge file-wide header arguments using the `org-babel-default-header-args' variable. Cheers -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hi Eric, Eric Schulte wrote: #+BABEL: :var SVNVERSION=(vc-working-revision (buffer-file-name)) #+BABEL: :var SVNSTATE=( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))) #+BABEL: :var SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13) which would look horrible in one line and a nightmare to edit. I can think of three options for how to handle this situation. 1. If it turns out to be possible/desirable my preferred solution here would be to add general property support for appending values to properties when properties are over specified rather than simply replacing the value. Perhaps this could be done with a variable like org-accumulating-properties which could hold a list of those properties which should accumulate values rather than overwriting them. 2. Adding a #+PROPERTY: line authoring helper similar to the table formula helper making it more natural to edit such long property lines. 3. It may be possible to add syntax for extending #+PROPERTY: specifications across multiple lines, something like #+PROPERTY: SVNVERSION=(vc-working-revision (buffer-file-name)), #+PROPERTY+: SVNSTATE=( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))), #+PROPERTY+: SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13), FWIW I would like to have a similar extender for #+TBLFM: lines. Actually this choice may be my preferred solution. What do you think? I think that makes sense. While thinking about all of this, and working in real-life documents, I just came back to a suggestion which I made some time ago. It goes about this enhancement: Would it be possible to specify buffer-wide language specific header arguments? That is, be able to say: In this document, I want to: - tangle all my .sql chunks, but no other; - eval all the elisp chunks with query, but no other. Something we could write quite easily along the lines: #+PROPERTY: tangle no #+PROPERTY: eval never #+PROPERTY[SQL]: tangle yes #+PROPERTY[EMACS-LISP]: eval query (the syntax used here is just a draft sample!) What do you think about this feature? If you feel it can be something interesting to have, this is surely to incorporate in the current syntax debate. If not... never mind. Best regards, Seb -- Sebastien Vauban
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On Tue, Oct 25, 2011 at 11:35 AM, Sebastien Vauban wxhgmqzgw...@spammotel.com wrote: Hi Eric, Eric Schulte wrote: #+BABEL: :var SVNVERSION=(vc-working-revision (buffer-file-name)) #+BABEL: :var SVNSTATE=( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))) #+BABEL: :var SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13) which would look horrible in one line and a nightmare to edit. I can think of three options for how to handle this situation. 1. If it turns out to be possible/desirable my preferred solution here would be to add general property support for appending values to properties when properties are over specified rather than simply replacing the value. Perhaps this could be done with a variable like org-accumulating-properties which could hold a list of those properties which should accumulate values rather than overwriting them. 2. Adding a #+PROPERTY: line authoring helper similar to the table formula helper making it more natural to edit such long property lines. 3. It may be possible to add syntax for extending #+PROPERTY: specifications across multiple lines, something like #+PROPERTY: SVNVERSION=(vc-working-revision (buffer-file-name)), #+PROPERTY+: SVNSTATE=( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))), #+PROPERTY+: SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13), FWIW I would like to have a similar extender for #+TBLFM: lines. Actually this choice may be my preferred solution. What do you think? I think that makes sense. While thinking about all of this, and working in real-life documents, I just came back to a suggestion which I made some time ago. It goes about this enhancement: Would it be possible to specify buffer-wide language specific header arguments? That is, be able to say: In this document, I want to: - tangle all my .sql chunks, but no other; - eval all the elisp chunks with query, but no other. Something we could write quite easily along the lines: #+PROPERTY: tangle no #+PROPERTY: eval never #+PROPERTY[SQL]: tangle yes #+PROPERTY[EMACS-LISP]: eval query (the syntax used here is just a draft sample!) What do you think about this feature? If you feel it can be something interesting to have, this is surely to incorporate in the current syntax debate. If not... never mind. I am not Eric, but I think that would be a good idea. Bu there needs to be a way of specifying more then one property, either by #+PROPERTY+: or by any other way -I acually luike the #+PROPERTY+: . Thinking about it, it should be possible without the +: #+PROPERTY[R]: tangle no #+PROPERTY[R]: export both The more I see it, the more I like it - also the [] Cheers, Rainer Best regards, Seb -- Sebastien Vauban -- 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 (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hi Rainer, Rainer M Krug wrote: While thinking about all of this, and working in real-life documents, I just came back to a suggestion which I made some time ago. It goes about this enhancement: Would it be possible to specify buffer-wide language specific header arguments? That is, be able to say: In this document, I want to: - tangle all my .sql chunks, but no other; - eval all the elisp chunks with query, but no other. Something we could write quite easily along the lines: #+PROPERTY: tangle no #+PROPERTY: eval never #+PROPERTY[SQL]: tangle yes #+PROPERTY[EMACS-LISP]: eval query (the syntax used here is just a draft sample!) What do you think about this feature? If you feel it can be something interesting to have, this is surely to incorporate in the current syntax debate. If not... never mind. I am not Eric, but I think that would be a good idea. Thanks for your comments. Bu there needs to be a way of specifying more then one property, either by #+PROPERTY+: or by any other way -I acually luike the #+PROPERTY+: . Thinking about it, it should be possible without the +: #+PROPERTY[R]: tangle no #+PROPERTY[R]: export both Yes, no need for a + here, as the lines do target different properties (in this case, tangle and export). The more I see it, the more I like it - also the [] In fact, the lines without any language specification would be, at least semantically, equivalent to something like this: #+PROPERTY[*]:tangle no #+PROPERTY[*]:eval never Best regards, Seb -- Sebastien Vauban
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On Tue, Oct 25, 2011 at 12:31 PM, Sebastien Vauban wxhgmqzgw...@spammotel.com wrote: Hi Rainer, Rainer M Krug wrote: While thinking about all of this, and working in real-life documents, I just came back to a suggestion which I made some time ago. It goes about this enhancement: Would it be possible to specify buffer-wide language specific header arguments? That is, be able to say: In this document, I want to: - tangle all my .sql chunks, but no other; - eval all the elisp chunks with query, but no other. Something we could write quite easily along the lines: #+PROPERTY: tangle no #+PROPERTY: eval never #+PROPERTY[SQL]: tangle yes #+PROPERTY[EMACS-LISP]: eval query (the syntax used here is just a draft sample!) What do you think about this feature? If you feel it can be something interesting to have, this is surely to incorporate in the current syntax debate. If not... never mind. I am not Eric, but I think that would be a good idea. Thanks for your comments. Bu there needs to be a way of specifying more then one property, either by #+PROPERTY+: or by any other way -I acually luike the #+PROPERTY+: . Thinking about it, it should be possible without the +: #+PROPERTY[R]: tangle no #+PROPERTY[R]: export both Yes, no need for a + here, as the lines do target different properties (in this case, tangle and export). The more I see it, the more I like it - also the [] In fact, the lines without any language specification would be, at least semantically, equivalent to something like this: #+PROPERTY[*]:tangle no #+PROPERTY[*]:eval never So #+PROPERTY followed by square brackets, means properties for source blocks of a given language, and [*] is the default and can be omitted. Two ideas: [R,sh], i.e. specifying a list of languages in the brackets could be useful, as well as wildcards like [dit*]? The latter less usefull, but for consistency? Additionally: it would be nice, if one could define a set of properties, and then recall them for certain blocks. e.g: #+PROPERTY[R:set1]: tangle no #+PROPERTY[R:set1]: eval never #+PROPERTY[R:set2]: tangle yes #+PROPERTY[R:set2]: export both #+src_begin R :set set1 cat(1) #+end would have the first set of properties (tangle no and eval never), where #+src_begin R :set set2 cat(1) #+end would have the second set of properties (tangle no and eval never) Might be a good addition? Cheers, Rainer Best regards, Seb -- Sebastien Vauban -- 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 (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
I think that makes sense. While thinking about all of this, and working in real-life documents, I just came back to a suggestion which I made some time ago. It goes about this enhancement: Would it be possible to specify buffer-wide language specific header arguments? Yes, this is already possible. You can customize the org-babel-default-header-args:lang variable (where lang is the source name) as a file local variable. That is, be able to say: In this document, I want to: - tangle all my .sql chunks, but no other; - eval all the elisp chunks with query, but no other. Something we could write quite easily along the lines: #+PROPERTY: tangle no #+PROPERTY: eval never #+PROPERTY[SQL]: tangle yes #+PROPERTY[EMACS-LISP]: eval query (the syntax used here is just a draft sample!) I do not think we can customize the PROPERTY syntax as is exists outside of Babel. The goal here was to piggy-back on top of rather than co-opt regular Org-mode syntax. Best -- Eric What do you think about this feature? If you feel it can be something interesting to have, this is surely to incorporate in the current syntax debate. If not... never mind. Best regards, Seb -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On Sat, Oct 22, 2011 at 9:58 AM, Christian Moe m...@christianmoe.comwrote: On 10/21/11 8:40 PM, Rainer M Krug wrote: Just to add to it: at the moment I have e.g: #+BABEL: :var MAINVERSION=0 #+BABEL: :var SVNVERSION=(vc-working-**revision (buffer-file-name)) #+BABEL: :var SVNSTATE=( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))) #+BABEL: :var SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13) #+BABEL: :var DISP_PACKAGE=seedDisp_0.4-13.**tar.gz which would look horrible in one line and a nightmare to edit. Any suggestions how this cold be changed? Wow. I guess I was wrong to imagine your problem was solved. If your code blocks share the same language, and it supports sessions, I'd bite the bullet and transform them into #+HEADERS lines for the first src block, then reuse them through a session. Does that make sense? If your variables are going to be used by different src blocks in different languages, I don't have any elegant solution. Yep - different languages: R and sh Yours, Christian -- 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 (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On Sat, Oct 22, 2011 at 5:52 PM, Eric Schulte schulte.e...@gmail.comwrote: Just to add to it: at the moment I have e.g: #+BABEL: :var MAINVERSION=0 #+BABEL: :var SVNVERSION=(vc-working-revision (buffer-file-name)) #+BABEL: :var SVNSTATE=( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))) #+BABEL: :var SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13) #+BABEL: :var DISP_PACKAGE=seedDisp_0.4-13.tar.gz which would look horrible in one line and a nightmare to edit. Any suggestions how this cold be changed? Hmm, I don't see any easy solution for the above. I'm sorry to have removed this functionality. I can think of three options for how to handle this situation. 1. If it turns out to be possible/desirable my preferred solution here would be to add general property support for appending values to properties when properties are over specified rather than simply replacing the value. Perhaps this could be done with a variable like org-accumulating-properties which could hold a list of those properties which should accumulate values rather than overwriting them. Should work, but will add an additional level of complexity which I think is avoidable. 2. Adding a #+PROPERTY: line authoring helper similar to the table formula helper making it more natural to edit such long property lines. I think this might be to complicated 3. It may be possible to add syntax for extending #+PROPERTY: specifications across multiple lines, something like #+PROPERTY: var MAINVERSION=0, #+PROPERTY+: SVNVERSION=(vc-working-revision (buffer-file-name)), #+PROPERTY+: SVNSTATE=( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))), #+PROPERTY+: SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13), #+PROPERTY+: DISP_PACKAGE=seedDisp_0.4-13.tar.gz FWIW I would like to have a similar extender for #+TBLFM: lines. Actually this choice may be my preferred solution. I like that suggestion - This would add an option, if inheritance for subtrees is incorporated for #+PROPERTY to unset all variables - something I was looking for some time ago. So I really like that solution: logical, clear, does not break anything, and easy to read - I would say go for it. What do you think? In addition: I would like to have a warning if #+BABEL is present in the org file, so that one remembers that it has to be changed. #+begin_src emacs-lisp (add-hook 'org-mode-hook (lambda () (save-excursion (goto-char (point-min)) (when (re-search-forward (org-make-options-regexp '(BABEL))) (message This file contains a \#+BABEL:\ line.) #+end_src Could this be included in the next few versions of org, as I can imnagine that especially infrequent org-babel users will be confused. Also: in a year, when I open an old org-file and it des not work, this would warn me about the necessary modifications. Cheers, Rainer Cheers -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/ -- 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 (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On Sat, Oct 22, 2011 at 9:07 PM, Christian Moe m...@christianmoe.comwrote: Hi, Eric Schulte wrote: I can think of three options for how to handle this situation. 1. If it turns out to be possible/desirable my preferred solution here would be to add general property support for appending values to properties when properties are over specified (...) 2. Adding a #+PROPERTY: line authoring helper similar to the table formula helper making it more natural to edit such long property lines. 3. It may be possible to add syntax for extending #+PROPERTY: specifications across multiple lines, something like #+PROPERTY: var MAINVERSION=0, #+PROPERTY+: SVNVERSION=(vc-working-**revision (buffer-file-name)), (...) These are all interesting ideas, as was Darlan's alternative suggestion to Eric's suggestion (1), namely to use a special inherit argument. I'd like to toss out a different idea, which I think is brilliant, but which may go down in flames once we've had a time to think it through. (And sorry if it's been proposed before; I came to Org just as Org-Babel was being stabilized.) In short, let Babel assign to any declared variables of a src block the values of any properties at point with the same name. In other words: - The :var header argument / :var: property could declare variables without assigning values, that is, you could have `:var foo=1, bar, baz=3' to tell Babel that `bar' is a variable too. - When a variable is declared, but no value assigned, Babel would look for a property (e.g. `:bar: 2') at point with the same name as the variable. - If property inheritance is turned on, this means a variable can be specified at any level of the outline. - If no further changes were made (such as the property accumulation Eric suggested), it would still be possible to /declare/ variables only at /one/ level of the outline besides in the code block and calls, since declarations all belong to the same `:var:' property. However, this approach would mean that declarations could be kept short and there would be a great deal of modularity in what values would be assigned. This all sounds very interesting, but I have problems understanding the advantages - possibly because I only had one coffee this morning. In addition see further down: SNIP On 10/22/11 5:52 PM, Eric Schulte wrote: #+BABEL: :var MAINVERSION=0 #+BABEL: :var SVNVERSION=(vc-working-**revision (buffer-file-name)) #+BABEL: :var SVNSTATE=( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))) #+BABEL: :var SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13) #+BABEL: :var DISP_PACKAGE=seedDisp_0.4-13.**tar.gz Have a buffer-level property for all the long lines (sorry if my email client wraps these lines): #+PROPERTY: SVNVERSION (vc-working-revision (buffer-file-name)) #+PROPERTY: SVNSTATE ( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))) #+PROPERTY: SVNSTATENUM (if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13) #+PROPERTY: DISP_PACKAGE seedDisp_0.4-13.tar.gz I think this syntax opens the door for dangerous typos - If you type e.g: #+PROPERTY: vat x=10 what would this be? it should have been #+PROPERTY: var x=10 but now? One could allow this syntax in the case that the variable has been defined before, by using the var syntax: so #+PROPERTY: var MAINVERSION=0, SVNVERSION, SVNSTATE, SVNSTATENUM, DISP_PACKAGE #+PROPERTY: SVNVERSION (vc-working-revision (buffer-file-name)) #+PROPERTY: SVNSTATE ( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))) #+PROPERTY: SVNSTATENUM (if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13) #+PROPERTY: DISP_PACKAGE seedDisp_0.4-13.tar.gz should be OK, as SVNVERSION is already defined, but #+PROPERTY: SVNVERSION (vc-working-revision (buffer-file-name)) #+PROPERTY: SVNSTATE ( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))) #+PROPERTY: SVNSTATENUM (if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13) #+PROPERTY: DISP_PACKAGE seedDisp_0.4-13.tar.gz #+PROPERTY: var MAINVERSION=0, SVNVERSION, SVNSTATE, SVNSTATENUM, DISP_PACKAGE not, as the variables are only defined later. But this would not make #+PROPERTY+: redundant, but rather enhance it. Cheers, Rainer Cheers, Rainer SNIP Yours, Christian -- 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 (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
This all sounds very interesting, but I have problems understanding the advantages - possibly because I only had one coffee this morning. It may not be feasible and the disadvantages may outnumber the advantages; we'll see. But having several coffees under my belt already, I'll argue my corner. :-) To recapitulate, I'm proposing that the values of (declared) variables for code blocks could be assigned from properties with the same names, so that: :PROPERTIES: :var: x=1, y=2, z=-3 :END: could also, and interchangeably, be written: :PROPERTIES: :x: 1 :y: 2 :z: -3 :var: x, y, z :END: Here setting the `var' property with variable names, but without assignments, would declare that the variables are to be passed to the src block, and prompt Babel to look for the values in properties with the same names. I think some of the advantages should be clear. First: -- It would easily let code blocks collect data from Org entry properties, without having to use lisp expressions or first collecting the properties in a dynamic block and then referencing the d.b. This would be nice particularly when your data is already in outline/property form. A second advantage: --- It would allow a great deal of flexibility in passing variables according to position in the outline hierarchy. #+BEGIN_EXAMPLE * Some default settings :PROPERTIES: :x: 1 :y: 2 :z: -3 :var: x, y, z :END: ** For all cases where y=5 :PROPERTIES: :y: 5 :END: *** A case where x=1, y=5, z=-3 #+begin_src R (...) #+end_src *** A case where x=1, y=5, z=8: no need to specify y again #+begin_src R :var z=8 (...) #+end_src (z could alternatively have been specified as a property, same as y above) #+END_EXAMPLE This modular re-use of values from higher up in the outline, on any number of levels, should more than compensate for the loss of buffer-wide assignments with the #+BABEL header. With a single :var: property for passing arguments, on the other hand, this is not possible. You have to re-assign values to all three variables on each level. (Note: Eric's idea for accumulative properties, on the other hand, /would/ allow you to do this with a single :var: property.) #+PROPERTY: SVNVERSION (vc-working-revision (buffer-file-name)) #+PROPERTY: SVNSTATE ( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))) #+PROPERTY: SVNSTATENUM (if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13) #+PROPERTY: DISP_PACKAGE seedDisp_0.4-13.tar.gz I think this syntax opens the door for dangerous typos - If you type e.g: #+PROPERTY: vat x=10 what would this be? it should have been #+PROPERTY: var x=10 but now? Now there would be a :vat: property with the value x=10. It will not be passed to any code block because (as I imagine the scheme) any variables to be passed to a code block still need to be /declared/ with a :var: property or :var header argument, so it will not conflict with any `vat' variable you might have defined in the code. Instead, you will notice the typo when your code block results in an error message that x is missing, same as now. The result of misspelling var under my scheme would be the same as misspelling it now. One could allow this syntax in the case that the variable has been defined before, by using the var syntax: To simplify your example, you think this is permissible: #+PROPERTY: var x, y, z #+PROPERTY: x 1 #+PROPERTY: y (1+ 1) #+PROPERTY: z (- 0 3) but this is not: #+PROPERTY: x 1 #+PROPERTY: y (1+ 1) #+PROPERTY: z (- 0 3) #+PROPERTY: var x, y, z As I imagine the scheme, it wouldn't matter and the two are interchangeable. The `#+PROPERTY: y (1+ 1)' assignment, in and of itself, would only create a property :y: with the string value (1+ 1). When Babel began to execute a code block, it would first look up the value of the property :var: at point to see what variables to pass, and the order of the PROPERTY headers is not important. It would then look for the values of the properties :x:, :y: and :z: at point, and only then, knowing that these are variables for a code block, would it evaluate any lisp expressions in these values. A third advantage: -- It would provide one way to solve your problem -- very long assignment expressions that are difficult to group on a line. It is not necessarily the best way to solve that specific problem, compared with the various options Eric came up with, such as #+PROPERTY+:. But this would not make #+PROPERTY+: redundant, but rather enhance it. Possibly; my solution only applies to the :var passed to a code block; there may be other property assignments that it would be good to be able to split over several lines. Also, I can certainly see the attraction of the analogous #+TBLFM+: -- though I'm fine with the existing `C-c '' solution for that, and
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hi all, Christian Moe wrote: This all sounds very interesting, but I have problems understanding the advantages - possibly because I only had one coffee this morning. I think some of the advantages should be clear. A second advantage: --- It would allow a great deal of flexibility in passing variables according to position in the outline hierarchy. #+BEGIN_EXAMPLE * Some default settings :PROPERTIES: :x: 1 :y: 2 :z: -3 :var: x, y, z :END: ** For all cases where y=5 :PROPERTIES: :y: 5 :END: *** A case where x=1, y=5, z=-3 #+begin_src R (...) #+end_src *** A case where x=1, y=5, z=8: no need to specify y again #+begin_src R :var z=8 (...) #+end_src (z could alternatively have been specified as a property, same as y above) #+END_EXAMPLE This modular re-use of values from higher up in the outline, on any number of levels, should more than compensate for the loss of buffer-wide assignments with the #+BABEL header. With a single :var: property for passing arguments, on the other hand, this is not possible. You have to re-assign values to all three variables on each level. (Note: Eric's idea for accumulative properties, on the other hand, /would/ allow you to do this with a single :var: property.) I think discussing all of this is beneficial and can lead to very interesting solutions. But I just have a comment on your second advantage, something that can render your example inefficient: inheritance is not on by default, and you need to enable if for *specific properties*. Make it on by default would be a very bad idea -- just think at examples of the mails sent through Org-mime: what about setting a Cc or To somewhere and inheriting that in all the file/subtree/etc. May be scary or inefficient performance-wise? Anyway, setting inheritance of properties to on, means you should declare the behavior for vars x, y and z, ie declaring it 3 times... Except, maybe, if you say that var: x, y, z does that too (then you've two things in one shot -- why not?). Best regards, Seb -- Sebastien Vauban
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On 10/24/11 2:11 PM, Sebastien Vauban wrote: (...) But I just have a comment on your second advantage, something that can render your example inefficient: inheritance is not on by default, and you need to enable if for *specific properties*. You can set `org-use-property-inheritance' to t, to make all properties inheritable, or you can set it to a list to enable specific properties. I suppose you meant that the former would be a bad idea. (And it could be, depending on your working habits, file size, outline nesting depth and the speed of your machine.) But you're right, property inheritance is not on by default and I forgot to mention that this time around. (I think I did mention it in the previous long message where I presented the idea.) Make it on by default would be a very bad idea -- just think at examples of the mails sent through Org-mime: what about setting a Cc or To somewhere and inheriting that in all the file/subtree/etc. May be scary or inefficient performance-wise? Anyway, setting inheritance of properties to on, means you should declare the behavior for vars x, y and z, ie declaring it 3 times... Except, maybe, if you say that var: x, y, z does that too (then you've two things in one shot -- why not?). Yes, if my suggestion becomes reality, this could be a useful refinement. Yours, Christian
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hello, Christian Moe m...@christianmoe.com writes: But you're right, property inheritance is not on by default and I forgot to mention that this time around. (I think I did mention it in the previous long message where I presented the idea.) AFAIK, Babel has always searched its properties with inheritance on, independently on user configuration. Thus, it doesn't matter much in that case. Regard, -- Nicolas Goaziou
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
I didn't check the list for 3 days and this thread became a little hard to follow. So, forgive me if I'm answering the wrong E-Mail. I liked Christian's idea of using a single var property to tell babel which regular properties it should use as variables (ignoring any variable not defined). This would be enough for my use cases. On the other hand, some way to append values to a property, such as using some special keyword as I have suggested, could be a better solution in order to keep consistence if people want this feature for non-babel related properties. -- Darlan At Sat, 22 Oct 2011 09:53:25 -0600, Eric Schulte wrote: Darlan Cavalcante Moreira darc...@gmail.com writes: It's excellent that now babel understands multiple values in the var property (I was one of the people that wanted this), but There Is One More Thing. Would it be feasible to inherit variables from parent sub-trees? Effectively, I'd like to append new values in lower level sub-trees, but AFAIK setting the var property in a sub-tree will still replace the value set in the parent sub-tree. Currently every new property specification entirely replaced previous specifications with the same name. That is, in the example below the level-2 sub-trees would not have the foo variable passed to babel. * Code with foo :PROPERTIES: :var: foo=1 :END: ** Code only with bar :PROPERTIES: :var: bar=2 :END: src_block ** Code only with baz :PROPERTIES: :var: baz=3 :END: src_block Maybe a special keyword, such as inherit (or append) could be used to incorporate variables defined in the parent sub-tree, such that the example would become * Code with foo :PROPERTIES: :var: foo=1 :END: ** Code with foo and bar :PROPERTIES: :var: bar=2, inherit :END: src_block ** Code with foo and baz :PROPERTIES: :var: baz=3, inherit :END: src_block This should not affect global variables and inherit would inherit variables defined only in the parent sub-tree (unless it also contains the inherit keyword). As a use case scenario, suppose I need to perform simulations for a few different scenarios, each with small variations. This would allow me to define common variables for a scenario in a higher level sub-tree and more specific variables in the lower level sub-trees. This sounds somewhat similar to my suggestion in reply to Rainer's email. Best -- Eric -- Darlan Cavalcante At Fri, 21 Oct 2011 22:24:25 +0200, Christian Moe m...@christianmoe.com wrote: Hi, Yes, that works nicely, and should solve Rainer's problem. I haven't been able to think of anything else that can't be handled by properties. And I do think it's a good idea to winnow down the syntax a bit, even if things break. I just like to grumble. :-) Yours, Christian On 10/21/11 7:37 PM, Eric Schulte wrote: Nice idea. This same issue with var arose when we first started allowing header arguments to be specified inside subtree properties. I've just implemented your suggestion so the following are now possible. #+PROPERTY: var foo=1, bar=2 #+PROPERTY: cache yes #+begin_src emacs-lisp (+ foo bar) #+end_src #+results[be32e67491d4e92f75769aebe423c20ca01626fe]: : 3 and #+begin_src emacs-lisp :var foo=this, bar=that (concat foo bar) #+end_src #+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]: : this that Thanks for the suggestion and I hope the above is a sufficient replacement for the now-missing #+BABEL: syntax. Cheers -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hi Darlan, Darlan Cavalcante Moreira wrote: It's excellent that now babel understands multiple values in the var property (I was one of the people that wanted this), but There Is One More Thing. Would it be feasible to inherit variables from parent sub-trees? Effectively, I'd like to append new values in lower level sub-trees, but AFAIK setting the var property in a sub-tree will still replace the value set in the parent sub-tree. #+PROPERTY: var foo=level0 * Overview Global vars and local-to-this-subtree vars seem correctly handled. Effectively, vars set in higher level trees are not passed correctly to the code block. * Test code :PROPERTIES: :var: bar=level1 :END: ** Using the different vars :PROPERTIES: :var: baz=level2 :END: #+srcname: test #+begin_src sh :var foo=valueforthiscodeblock echo $foo echo $bar echo $baz #+end_src #+results: test | valueforthiscodeblock | | | | level2| As you can see, the bar variable is unknown to the code block. Best regards, Seb -- Sebastien Vauban
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On 10/21/11 8:40 PM, Rainer M Krug wrote: Just to add to it: at the moment I have e.g: #+BABEL: :var MAINVERSION=0 #+BABEL: :var SVNVERSION=(vc-working-revision (buffer-file-name)) #+BABEL: :var SVNSTATE=( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))) #+BABEL: :var SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13) #+BABEL: :var DISP_PACKAGE=seedDisp_0.4-13.tar.gz which would look horrible in one line and a nightmare to edit. Any suggestions how this cold be changed? Wow. I guess I was wrong to imagine your problem was solved. If your code blocks share the same language, and it supports sessions, I'd bite the bullet and transform them into #+HEADERS lines for the first src block, then reuse them through a session. Does that make sense? If your variables are going to be used by different src blocks in different languages, I don't have any elegant solution. Yours, Christian
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Will #+PROPERTY: var foo=1 #+PROPERTY: var bar=2 also work, or result in one variable not signed? Try it out :) This is a question about property behavior not specific to code blocks. I believe that the second line will override the first, which is why it was necessary to be able to specify multiple variables in a single #+PROPERTY: instance. Cheers -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Just to clarify my understanding: on a #+PROPERTY line, you *have* to say #+PROPERTY: var a=1, b=2 but in the code block itself, you can say *either* #+begin_src emacs-lisp :var a=1, b=2 ... *or* #+begin_src emacs-lisp :var a=1 :var b=2 ... correct Experimentally, both of these currently work: do you have any plans to outlaw the last form? no Also, how does the comma-separated list of variable assignments interact with a language where comma has syntactic significance? I was primarily thinking of python where e.g. a=[1,2,3] or a=(1,2) is a legal construct. AFAICT, that never worked in babel[fn:1], so it may not matter much, but it may be a good idea to come up with a quoting mechanism so things like that can be added in the future if necessary. The syntax of the language is not used in the header argument form, only code-block constructs are used here, which largely amounts to data and code block references, indexing into variables, and emacs-lisp forms. There are cases where the above do contain , but they are parsed correctly, e.g., #+headers: :var data=foo(bar=1, baz=2), fuz=5 and #+headers: :var data=table[0,0] will both be parsed correctly. Thanks, Nick Footnotes: [fn:1] I checked in 7.7 to avoid the recent churn with the following code block #+begin_src python :var a='(1,2)' len(a) #+end_src and I get , | File stdin, line 3 | a=[1, [\,, 2]] | ^ | SyntaxError: unexpected character after line continuation character ` in the org babel error output buffer. you can use elisp in assignment forms, but not syntax from the language of the code block, so the above could be re-written as #+begin_src python :var a='(1 2) len(a) #+end_src -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Just to add to it: at the moment I have e.g: #+BABEL: :var MAINVERSION=0 #+BABEL: :var SVNVERSION=(vc-working-revision (buffer-file-name)) #+BABEL: :var SVNSTATE=( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))) #+BABEL: :var SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13) #+BABEL: :var DISP_PACKAGE=seedDisp_0.4-13.tar.gz which would look horrible in one line and a nightmare to edit. Any suggestions how this cold be changed? Hmm, I don't see any easy solution for the above. I'm sorry to have removed this functionality. I can think of three options for how to handle this situation. 1. If it turns out to be possible/desirable my preferred solution here would be to add general property support for appending values to properties when properties are over specified rather than simply replacing the value. Perhaps this could be done with a variable like org-accumulating-properties which could hold a list of those properties which should accumulate values rather than overwriting them. 2. Adding a #+PROPERTY: line authoring helper similar to the table formula helper making it more natural to edit such long property lines. 3. It may be possible to add syntax for extending #+PROPERTY: specifications across multiple lines, something like #+PROPERTY: var MAINVERSION=0, #+PROPERTY+: SVNVERSION=(vc-working-revision (buffer-file-name)), #+PROPERTY+: SVNSTATE=( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))), #+PROPERTY+: SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13), #+PROPERTY+: DISP_PACKAGE=seedDisp_0.4-13.tar.gz FWIW I would like to have a similar extender for #+TBLFM: lines. Actually this choice may be my preferred solution. What do you think? In addition: I would like to have a warning if #+BABEL is present in the org file, so that one remembers that it has to be changed. #+begin_src emacs-lisp (add-hook 'org-mode-hook (lambda () (save-excursion (goto-char (point-min)) (when (re-search-forward (org-make-options-regexp '(BABEL))) (message This file contains a \#+BABEL:\ line.) #+end_src Cheers -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Darlan Cavalcante Moreira darc...@gmail.com writes: It's excellent that now babel understands multiple values in the var property (I was one of the people that wanted this), but There Is One More Thing. Would it be feasible to inherit variables from parent sub-trees? Effectively, I'd like to append new values in lower level sub-trees, but AFAIK setting the var property in a sub-tree will still replace the value set in the parent sub-tree. Currently every new property specification entirely replaced previous specifications with the same name. That is, in the example below the level-2 sub-trees would not have the foo variable passed to babel. * Code with foo :PROPERTIES: :var: foo=1 :END: ** Code only with bar :PROPERTIES: :var: bar=2 :END: src_block ** Code only with baz :PROPERTIES: :var: baz=3 :END: src_block Maybe a special keyword, such as inherit (or append) could be used to incorporate variables defined in the parent sub-tree, such that the example would become * Code with foo :PROPERTIES: :var: foo=1 :END: ** Code with foo and bar :PROPERTIES: :var: bar=2, inherit :END: src_block ** Code with foo and baz :PROPERTIES: :var: baz=3, inherit :END: src_block This should not affect global variables and inherit would inherit variables defined only in the parent sub-tree (unless it also contains the inherit keyword). As a use case scenario, suppose I need to perform simulations for a few different scenarios, each with small variations. This would allow me to define common variables for a scenario in a higher level sub-tree and more specific variables in the lower level sub-trees. This sounds somewhat similar to my suggestion in reply to Rainer's email. Best -- Eric -- Darlan Cavalcante At Fri, 21 Oct 2011 22:24:25 +0200, Christian Moe m...@christianmoe.com wrote: Hi, Yes, that works nicely, and should solve Rainer's problem. I haven't been able to think of anything else that can't be handled by properties. And I do think it's a good idea to winnow down the syntax a bit, even if things break. I just like to grumble. :-) Yours, Christian On 10/21/11 7:37 PM, Eric Schulte wrote: Nice idea. This same issue with var arose when we first started allowing header arguments to be specified inside subtree properties. I've just implemented your suggestion so the following are now possible. #+PROPERTY: var foo=1, bar=2 #+PROPERTY: cache yes #+begin_src emacs-lisp (+ foo bar) #+end_src #+results[be32e67491d4e92f75769aebe423c20ca01626fe]: : 3 and #+begin_src emacs-lisp :var foo=this, bar=that (concat foo bar) #+end_src #+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]: : this that Thanks for the suggestion and I hope the above is a sufficient replacement for the now-missing #+BABEL: syntax. Cheers -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hi, Eric Schulte wrote: I can think of three options for how to handle this situation. 1. If it turns out to be possible/desirable my preferred solution here would be to add general property support for appending values to properties when properties are over specified (...) 2. Adding a #+PROPERTY: line authoring helper similar to the table formula helper making it more natural to edit such long property lines. 3. It may be possible to add syntax for extending #+PROPERTY: specifications across multiple lines, something like #+PROPERTY: var MAINVERSION=0, #+PROPERTY+: SVNVERSION=(vc-working-revision (buffer-file-name)), (...) These are all interesting ideas, as was Darlan's alternative suggestion to Eric's suggestion (1), namely to use a special inherit argument. I'd like to toss out a different idea, which I think is brilliant, but which may go down in flames once we've had a time to think it through. (And sorry if it's been proposed before; I came to Org just as Org-Babel was being stabilized.) In short, let Babel assign to any declared variables of a src block the values of any properties at point with the same name. In other words: - The :var header argument / :var: property could declare variables without assigning values, that is, you could have `:var foo=1, bar, baz=3' to tell Babel that `bar' is a variable too. - When a variable is declared, but no value assigned, Babel would look for a property (e.g. `:bar: 2') at point with the same name as the variable. - If property inheritance is turned on, this means a variable can be specified at any level of the outline. - If no further changes were made (such as the property accumulation Eric suggested), it would still be possible to /declare/ variables only at /one/ level of the outline besides in the code block and calls, since declarations all belong to the same `:var:' property. However, this approach would mean that declarations could be kept short and there would be a great deal of modularity in what values would be assigned. Two examples follow. --- Example 1. Darlan suggested a special inherit argument, as follows: * Code with foo :PROPERTIES: :var: foo=1 :END: ** Code with foo and bar :PROPERTIES: :var: bar=2, inherit :END: src_block ** Code with foo and baz :PROPERTIES: :var: baz=3, inherit :END: src_block Here is the same example under my proposal and with property inheritance turned on: * Code with foo :PROPERTIES: :foo: 1 :END: ** Code with foo and bar :PROPERTIES: :bar: 2 :END: src_block :var foo, bar ** Code with foo and baz :PROPERTIES: :baz: 3 :END: src_block :var foo, baz Instead of declaring foo,bar and foo,baz in the src_blocks, we could define them once and for all at the top of the outline: * Code with foo :PROPERTIES: :foo: 1 :var: foo, bar, baz :END: ** Code with foo and bar :PROPERTIES: :bar: 2 :END: src_block ** Code with foo and baz :PROPERTIES: :baz: 3 :END: src_block Under the first subhead, Org-babel would know (because the :var: property is inherited) to look for foo, bar and baz properties. It would find values for foo and bar (bar is defined as a property of that subhead, foo is inherited from the top-level heading). It would not find any value for baz. At this point, since no value could be assigned to baz, it would be ignored and would not be passed to the code block. --- Example 2. Let's take Rainer's problem : On 10/22/11 5:52 PM, Eric Schulte wrote: #+BABEL: :var MAINVERSION=0 #+BABEL: :var SVNVERSION=(vc-working-revision (buffer-file-name)) #+BABEL: :var SVNSTATE=( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))) #+BABEL: :var SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13) #+BABEL: :var DISP_PACKAGE=seedDisp_0.4-13.tar.gz Have a buffer-level property for all the long lines (sorry if my email client wraps these lines): #+PROPERTY: SVNVERSION (vc-working-revision (buffer-file-name)) #+PROPERTY: SVNSTATE ( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))) #+PROPERTY: SVNSTATENUM (if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13) #+PROPERTY: DISP_PACKAGE seedDisp_0.4-13.tar.gz Also, we have a buffer-level line declaring all these variables, and including MAINVERSION with the ordinary assignment. Thanks to last night's change, we can list them all on one line. #+PROPERTY: var MAINVERSION=0, SVNVERSION, SVNSTATE, SVNSTATENUM, DISP_PACKAGE I don't know what kind of code this example applies to, but let's imagine that we also have a header that resets one of these properties: * Variant for main version 1 :PROPERTIES: :MAINVERSION: 1 :END: ...and below that, we finally have a code block, with a header that declares a variable locally: #+HEADERS: :var
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hi Eric and Nick, Eric Schulte wrote: Nick Dokos nicholas.do...@hp.com writes: Eric Schulte schulte.e...@gmail.com wrote: Other than colon confusion (having to specify ``:results silent'' on the src block header line and ``results silent'' in the #+PROPERTY line to get the same behavior), this looks better. Not sure what (if anything) can or should be done about the colons. I don't know of a good solution for colons. If we decided to add colons then the subtree property blocks would become akward, with entries like ** foo :PROPERTIES: ::results: silent :END: I would say we could look for each value both with and without colons, but property searches of this nature are slow and doubling the speed impact simply for allow colon flexibility doesn't seem to be a good tradeoff. I think this will just have to be something that users will need to learn. [fn:1] ...but I take some perverse pleasure from the fact that both Suvayu and Seb asked the question :-) I noticed that too, and it no doubt means that this same question will occur to future users. I knew there was no beginning colon in the #+PROPERTY line (and that does not bother me). For example, how do we translate, in the new syntax, #+BABEL::results output code append (where `:results' is the name, and `output', `code' and `append' are values)? The above would become #+PROPERTY: results output code append Since only one property may be specified per property line there is no need for colons. This mirrors exactly the way the properties are saved under subtrees in :PROPERTY: blocks. Multiple lines may be used to specify multiple properties. e.g., #+PROPERTY: results silent #+PROPERTY: cache yes *But* I did not know it was limited to _one property per line_. Knowing that: - there is no confusion at all -- we simply (have to) know that the first word is the name without colon, and the rest are values - my argument in favor of #+PROPERTIES (over #+PROPERTY) simply falls. To sum up, I'm perfectly happy with the new choice. Best regards, Seb -- Sebastien Vauban
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hi again, I can quickly think of two advantages of the late lamented (if only by me) #+BABEL header over using properties. 1. Allowing you to specify multiple buffer-wide options on the same line (keeping things short), in the same colon :syntax as used in a src block header (keeping things consistent and easy to copy back and forth). None of this makes a substantive difference. 2. Allowing you to pass multiple buffer-wide arguments with :var. This could make a substantive difference in some applications. The following will work: #+BABEL: :var euro=1.3791 :var salestax=.15 The following will not, since it tries to set the same property: #+PROPERTY: var euro=1.3791 #+PROPERTY: var salestax=.15 If BABEL is dropped for PROPERTY, it would be good for the :var: property to support multiple arguments (comma-separated would be good for consistency with passing arguments through the SRCNAME). E.g.: #+PROPERTY: var euro=1.3791, salestax=.15 I think I'd like this better in any case. Yours, Christian On 10/21/11 9:28 AM, Sebastien Vauban wrote: Multiple lines may be used to specify multiple properties. e.g., #+PROPERTY: results silent #+PROPERTY: cache yes *But* I did not know it was limited to _one property per line_. Knowing that: - there is no confusion at all -- we simply (have to) know that the first word is the name without colon, and the rest are values - my argument in favor of #+PROPERTIES (over #+PROPERTY) simply falls. To sum up, I'm perfectly happy with the new choice. Best regards, Seb
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On Fri, Oct 21, 2011 at 10:14 AM, Christian Moe m...@christianmoe.comwrote: Hi again, I can quickly think of two advantages of the late lamented (if only by me) #+BABEL header over using properties. I also think that keeping the #+BABEL would be a good idea, as it keeps the options for babel separate (as are the functions - org-babel... ). It is true that babel is getting more and more interwined with org (which is a good think), but especially in my case, I use org more or less exclusively for literate programming (babel) and some org features (archiving, note capture...) in this context, it would be really nice to be able to keep the options for babel easily identifyable. I defined a new drawer (:BABEL:) and put my options / arguments / properties for babel in there. So my question would be: would i be possible to leave #+BABEL as an equivalent for #+PROPERTY ? Yes, it could be misused, but also used to make these options easily identifyable. My setup at the moment: #+DRAWERS: HIDDEN PROPERTIES STATE CONFIG BABEL OUTPUT LATEX :BABEL: #+BABEL: :session *R* #+BABEL: :results output #+BABEL: :exports code #+BABEL: :comments yes #+BABEL: :tangle Analysis_sensitivity.R #+BABEL: :var RESULTSDIR=/media/Results/clusterResults/nsa/LHCube/nsa.91.up-to-date/results/ #+BABEL: :var ANALYSISDIR=/home/rkrug/Documents/Projects/BiocontrolAndAlienDynamics/nonSpatialAcacia/LHCube/nsa.91.up-to-date/analysis/ :END: 1. Allowing you to specify multiple buffer-wide options on the same line (keeping things short), in the same colon :syntax as used in a src block header (keeping things consistent and easy to copy back and forth). None of this makes a substantive difference. 2. Allowing you to pass multiple buffer-wide arguments with :var. This could make a substantive difference in some applications. The following will work: #+BABEL: :var euro=1.3791 :var salestax=.15 The following will not, since it tries to set the same property: #+PROPERTY: var euro=1.3791 #+PROPERTY: var salestax=.15 I think it is a very important point, that the construct with :var still works - but as Eric only mentioned the *naming*, I assume that in the actual usage nothing changes. OK - the colon at the beginning - but I clud live with that change, although it makes it clear what the actual argument is which is set. If BABEL is dropped for PROPERTY, it would be good for the :var: property to support multiple arguments (comma-separated would be good for consistency with passing arguments through the SRCNAME). E.g.: #+PROPERTY: var euro=1.3791, salestax=.15 I think that would be a good idea, but I think that was already discussed some time ago and rejected? I think I'd like this better in any case. No - rather in separate lines... but different strokes for different folks... Cheers, Rainer Yours, Christian On 10/21/11 9:28 AM, Sebastien Vauban wrote: Multiple lines may be used to specify multiple properties. e.g., #+PROPERTY: results silent #+PROPERTY: cache yes *But* I did not know it was limited to _one property per line_. Knowing that: - there is no confusion at all -- we simply (have to) know that the first word is the name without colon, and the rest are values - my argument in favor of #+PROPERTIES (over #+PROPERTY) simply falls. To sum up, I'm perfectly happy with the new choice. Best regards, Seb -- 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 (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On 10/21/11 11:12 AM, Rainer M Krug wrote: On Fri, Oct 21, 2011 at 10:14 AM, Christian Moe m...@christianmoe.com mailto:m...@christianmoe.com wrote: (...) 2. Allowing you to pass multiple buffer-wide arguments with :var. This could make a substantive difference in some applications. The following will work: #+BABEL: :var euro=1.3791 :var salestax=.15 The following will not, since it tries to set the same property: #+PROPERTY: var euro=1.3791 #+PROPERTY: var salestax=.15 I think it is a very important point, that the construct with :var still works - but as Eric only mentioned the *naming*, I assume that in the actual usage nothing changes. Hi, Rainer, My point was that there is at least one (minor) case where properties are not functionally equivalent to the BABEL line: You cannot pass arguments for more than one variable buffer-wide, because you can't have multiple var properties at the same time, and at present, one var property only sets one variable. The behavior of properties has not changed. What has changed is the removal of the BABEL header, whose colon (:var) syntax did allow you to set multiple variables buffer-wide should you wish to. Yours, Christian
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On Fri, Oct 21, 2011 at 12:47 PM, Christian Moe m...@christianmoe.comwrote: On 10/21/11 11:12 AM, Rainer M Krug wrote: On Fri, Oct 21, 2011 at 10:14 AM, Christian Moe m...@christianmoe.com mailto:m...@christianmoe.com** wrote: (...) 2. Allowing you to pass multiple buffer-wide arguments with :var. This could make a substantive difference in some applications. The following will work: #+BABEL: :var euro=1.3791 :var salestax=.15 The following will not, since it tries to set the same property: #+PROPERTY: var euro=1.3791 #+PROPERTY: var salestax=.15 I think it is a very important point, that the construct with :var still works - but as Eric only mentioned the *naming*, I assume that in the actual usage nothing changes. Hi, Rainer, My point was that there is at least one (minor) case where properties are not functionally equivalent to the BABEL line: You cannot pass arguments for more than one variable buffer-wide, because you can't have multiple var properties at the same time, and at present, one var property only sets one variable. So, using your above mentioned example, after the first PROPERTY line, euro=1.3795 and SALESTAX not set, while after the second one salestax=.15, and euro is unset? That would be quite bad. The behavior of properties has not changed. What has changed is the removal of the BABEL header, whose colon (:var) syntax did allow you to set multiple variables buffer-wide should you wish to. To clarify: before, we could use #+BABEL and #PROPERTY to do similar things. Now the whole #+BABEL has been removed, and only the functionality from #+PROPERTY is left - correct? Rainer Yours, Christian -- 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 (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On 10/21/11 12:59 PM, Rainer M Krug wrote: So, using your above mentioned example, after the first PROPERTY line, euro=1.3795 and SALESTAX not set, while after the second one salestax=.15, and euro is unset? That would be quite bad. That's what I'd expected, but actually, euro is set and salestax is not. Apparently subsequent PROPERTY lines are ignored if they try to set an already existing property. To clarify: before, we could use #+BABEL and #PROPERTY to do similar things. Now the whole #+BABEL has been removed, and only the functionality from #+PROPERTY is left - correct? That's my understanding. And #+PROPERTY offers equivalent functionality in almost every way, but not, as far as I can understand, in this corner case. Christian
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On Fri, Oct 21, 2011 at 1:17 PM, Christian Moe m...@christianmoe.comwrote: On 10/21/11 12:59 PM, Rainer M Krug wrote: So, using your above mentioned example, after the first PROPERTY line, euro=1.3795 and SALESTAX not set, while after the second one salestax=.15, and euro is unset? That would be quite bad. That's what I'd expected, but actually, euro is set and salestax is not. Apparently subsequent PROPERTY lines are ignored if they try to set an already existing property. That's bad - really bad. Because then I have to substantially change my files. To clarify: before, we could use #+BABEL and #PROPERTY to do similar things. Now the whole #+BABEL has been removed, and only the functionality from #+PROPERTY is left - correct? That's my understanding. And #+PROPERTY offers equivalent functionality in almost every way, but not, as far as I can understand, in this corner case. Then I would suggest to leave #+BABEL until these cases are also implemented in #+PROPERTY - but I suppose, they are there for a purpose. Cheers, Rainer Christian -- 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 (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Christian Moe m...@christianmoe.com writes: Hi again, I can quickly think of two advantages of the late lamented (if only by me) #+BABEL header over using properties. 1. Allowing you to specify multiple buffer-wide options on the same line (keeping things short), in the same colon :syntax as used in a src block header (keeping things consistent and easy to copy back and forth). None of this makes a substantive difference. Understood, the new method will require multiple lines. Everything is a trade-off... 2. Allowing you to pass multiple buffer-wide arguments with :var. This could make a substantive difference in some applications. The following will work: #+BABEL: :var euro=1.3791 :var salestax=.15 The following will not, since it tries to set the same property: #+PROPERTY: var euro=1.3791 #+PROPERTY: var salestax=.15 If BABEL is dropped for PROPERTY, it would be good for the :var: property to support multiple arguments (comma-separated would be good for consistency with passing arguments through the SRCNAME). E.g.: #+PROPERTY: var euro=1.3791, salestax=.15 I think I'd like this better in any case. Nice idea. This same issue with var arose when we first started allowing header arguments to be specified inside subtree properties. I've just implemented your suggestion so the following are now possible. #+PROPERTY: var foo=1, bar=2 #+PROPERTY: cache yes #+begin_src emacs-lisp (+ foo bar) #+end_src #+results[be32e67491d4e92f75769aebe423c20ca01626fe]: : 3 and #+begin_src emacs-lisp :var foo=this, bar=that (concat foo bar) #+end_src #+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]: : this that Thanks for the suggestion and I hope the above is a sufficient replacement for the now-missing #+BABEL: syntax. Cheers -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Eric Schulte schulte.e...@gmail.com wrote: 2. Allowing you to pass multiple buffer-wide arguments with :var. This could make a substantive difference in some applications. The following will work: #+BABEL: :var euro=1.3791 :var salestax=.15 The following will not, since it tries to set the same property: #+PROPERTY: var euro=1.3791 #+PROPERTY: var salestax=.15 If BABEL is dropped for PROPERTY, it would be good for the :var: property to support multiple arguments (comma-separated would be good for consistency with passing arguments through the SRCNAME). E.g.: #+PROPERTY: var euro=1.3791, salestax=.15 I think I'd like this better in any case. Nice idea. This same issue with var arose when we first started allowing header arguments to be specified inside subtree properties. I've just implemented your suggestion so the following are now possible. #+PROPERTY: var foo=1, bar=2 #+PROPERTY: cache yes #+begin_src emacs-lisp (+ foo bar) #+end_src #+results[be32e67491d4e92f75769aebe423c20ca01626fe]: : 3 and #+begin_src emacs-lisp :var foo=this, bar=that (concat foo bar) #+end_src #+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]: : this that Thanks for the suggestion and I hope the above is a sufficient replacement for the now-missing #+BABEL: syntax. Just to clarify my understanding: on a #+PROPERTY line, you *have* to say #+PROPERTY: var a=1, b=2 but in the code block itself, you can say *either* #+begin_src emacs-lisp :var a=1, b=2 ... *or* #+begin_src emacs-lisp :var a=1 :var b=2 ... Experimentally, both of these currently work: do you have any plans to outlaw the last form? Also, how does the comma-separated list of variable assignments interact with a language where comma has syntactic significance? I was primarily thinking of python where e.g. a=[1,2,3] or a=(1,2) is a legal construct. AFAICT, that never worked in babel[fn:1], so it may not matter much, but it may be a good idea to come up with a quoting mechanism so things like that can be added in the future if necessary. Thanks, Nick Footnotes: [fn:1] I checked in 7.7 to avoid the recent churn with the following code block #+begin_src python :var a='(1,2)' len(a) #+end_src and I get , | File stdin, line 3 | a=[1, [\,, 2]] | ^ | SyntaxError: unexpected character after line continuation character ` in the org babel error output buffer.
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On Fri, Oct 21, 2011 at 7:37 PM, Eric Schulte schulte.e...@gmail.comwrote: Christian Moe m...@christianmoe.com writes: Hi again, I can quickly think of two advantages of the late lamented (if only by me) #+BABEL header over using properties. 1. Allowing you to specify multiple buffer-wide options on the same line (keeping things short), in the same colon :syntax as used in a src block header (keeping things consistent and easy to copy back and forth). None of this makes a substantive difference. Understood, the new method will require multiple lines. Everything is a trade-off... 2. Allowing you to pass multiple buffer-wide arguments with :var. This could make a substantive difference in some applications. The following will work: #+BABEL: :var euro=1.3791 :var salestax=.15 The following will not, since it tries to set the same property: #+PROPERTY: var euro=1.3791 #+PROPERTY: var salestax=.15 If BABEL is dropped for PROPERTY, it would be good for the :var: property to support multiple arguments (comma-separated would be good for consistency with passing arguments through the SRCNAME). E.g.: #+PROPERTY: var euro=1.3791, salestax=.15 I think I'd like this better in any case. Nice idea. This same issue with var arose when we first started allowing header arguments to be specified inside subtree properties. I've just implemented your suggestion so the following are now possible. #+PROPERTY: var foo=1, bar=2 #+PROPERTY: cache yes #+begin_src emacs-lisp (+ foo bar) #+end_src #+results[be32e67491d4e92f75769aebe423c20ca01626fe]: : 3 Will #+PROPERTY: var foo=1 #+PROPERTY: var bar=2 also work, or result in one variable not signed? Rainer and #+begin_src emacs-lisp :var foo=this, bar=that (concat foo bar) #+end_src #+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]: : this that Thanks for the suggestion and I hope the above is a sufficient replacement for the now-missing #+BABEL: syntax. Cheers -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/ -- 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 (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On Fri, Oct 21, 2011 at 8:35 PM, Rainer M Krug r.m.k...@gmail.com wrote: On Fri, Oct 21, 2011 at 7:37 PM, Eric Schulte schulte.e...@gmail.comwrote: Christian Moe m...@christianmoe.com writes: Hi again, I can quickly think of two advantages of the late lamented (if only by me) #+BABEL header over using properties. 1. Allowing you to specify multiple buffer-wide options on the same line (keeping things short), in the same colon :syntax as used in a src block header (keeping things consistent and easy to copy back and forth). None of this makes a substantive difference. Understood, the new method will require multiple lines. Everything is a trade-off... 2. Allowing you to pass multiple buffer-wide arguments with :var. This could make a substantive difference in some applications. The following will work: #+BABEL: :var euro=1.3791 :var salestax=.15 The following will not, since it tries to set the same property: #+PROPERTY: var euro=1.3791 #+PROPERTY: var salestax=.15 If BABEL is dropped for PROPERTY, it would be good for the :var: property to support multiple arguments (comma-separated would be good for consistency with passing arguments through the SRCNAME). E.g.: #+PROPERTY: var euro=1.3791, salestax=.15 I think I'd like this better in any case. Nice idea. This same issue with var arose when we first started allowing header arguments to be specified inside subtree properties. I've just implemented your suggestion so the following are now possible. #+PROPERTY: var foo=1, bar=2 #+PROPERTY: cache yes #+begin_src emacs-lisp (+ foo bar) #+end_src #+results[be32e67491d4e92f75769aebe423c20ca01626fe]: : 3 Will #+PROPERTY: var foo=1 #+PROPERTY: var bar=2 also work, or result in one variable not signed? Rainer Just to add to it: at the moment I have e.g: #+BABEL: :var MAINVERSION=0 #+BABEL: :var SVNVERSION=(vc-working-revision (buffer-file-name)) #+BABEL: :var SVNSTATE=( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))) #+BABEL: :var SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13) #+BABEL: :var DISP_PACKAGE=seedDisp_0.4-13.tar.gz which would look horrible in one line and a nightmare to edit. Any suggestions how this cold be changed? In addition: I would like to have a warning if #+BABEL is present in the org file, so that one remembers that it has to be changed. Cheers, Rainer and #+begin_src emacs-lisp :var foo=this, bar=that (concat foo bar) #+end_src #+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]: : this that Thanks for the suggestion and I hope the above is a sufficient replacement for the now-missing #+BABEL: syntax. Cheers -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/ -- 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 (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -- 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 (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hi, Yes, that works nicely, and should solve Rainer's problem. I haven't been able to think of anything else that can't be handled by properties. And I do think it's a good idea to winnow down the syntax a bit, even if things break. I just like to grumble. :-) Yours, Christian On 10/21/11 7:37 PM, Eric Schulte wrote: Nice idea. This same issue with var arose when we first started allowing header arguments to be specified inside subtree properties. I've just implemented your suggestion so the following are now possible. #+PROPERTY: var foo=1, bar=2 #+PROPERTY: cache yes #+begin_src emacs-lisp (+ foo bar) #+end_src #+results[be32e67491d4e92f75769aebe423c20ca01626fe]: : 3 and #+begin_src emacs-lisp :var foo=this, bar=that (concat foo bar) #+end_src #+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]: : this that Thanks for the suggestion and I hope the above is a sufficient replacement for the now-missing #+BABEL: syntax. Cheers -- Eric
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
It's excellent that now babel understands multiple values in the var property (I was one of the people that wanted this), but There Is One More Thing. Would it be feasible to inherit variables from parent sub-trees? Effectively, I'd like to append new values in lower level sub-trees, but AFAIK setting the var property in a sub-tree will still replace the value set in the parent sub-tree. That is, in the example below the level-2 sub-trees would not have the foo variable passed to babel. --8---cut here---start-8--- * Code with foo :PROPERTIES: :var: foo=1 :END: ** Code only with bar :PROPERTIES: :var: bar=2 :END: src_block ** Code only with baz :PROPERTIES: :var: baz=3 :END: src_block --8---cut here---end---8--- Maybe a special keyword, such as inherit (or append) could be used to incorporate variables defined in the parent sub-tree, such that the example would become --8---cut here---start-8--- * Code with foo :PROPERTIES: :var: foo=1 :END: ** Code with foo and bar :PROPERTIES: :var: bar=2, inherit :END: src_block ** Code with foo and baz :PROPERTIES: :var: baz=3, inherit :END: src_block --8---cut here---end---8--- This should not affect global variables and inherit would inherit variables defined only in the parent sub-tree (unless it also contains the inherit keyword). As a use case scenario, suppose I need to perform simulations for a few different scenarios, each with small variations. This would allow me to define common variables for a scenario in a higher level sub-tree and more specific variables in the lower level sub-trees. -- Darlan Cavalcante At Fri, 21 Oct 2011 22:24:25 +0200, Christian Moe m...@christianmoe.com wrote: Hi, Yes, that works nicely, and should solve Rainer's problem. I haven't been able to think of anything else that can't be handled by properties. And I do think it's a good idea to winnow down the syntax a bit, even if things break. I just like to grumble. :-) Yours, Christian On 10/21/11 7:37 PM, Eric Schulte wrote: Nice idea. This same issue with var arose when we first started allowing header arguments to be specified inside subtree properties. I've just implemented your suggestion so the following are now possible. #+PROPERTY: var foo=1, bar=2 #+PROPERTY: cache yes #+begin_src emacs-lisp (+ foo bar) #+end_src #+results[be32e67491d4e92f75769aebe423c20ca01626fe]: : 3 and #+begin_src emacs-lisp :var foo=this, bar=that (concat foo bar) #+end_src #+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]: : this that Thanks for the suggestion and I hope the above is a sufficient replacement for the now-missing #+BABEL: syntax. Cheers -- Eric
[O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hi, I have just pushed up a change to the Org-mode git repository which removes support for #+BABEL lines. Please use the more general #+PROPERTIES lines instead. Best -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Eric Schulte schulte.e...@gmail.com wrote: I have just pushed up a change to the Org-mode git repository which removes support for #+BABEL lines. Please use the more general #+PROPERTIES lines instead. Coming late to the dance - sorry. I think that's very confusing. Property is an overloaded term in org: we now have the :PROPERTIES: drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and plural forms are already pretty bad). Also, there is the general concept of properties (the stuff that the property API applies to). Unless there is an underlying unity of which I'm unaware, I'd strongly suggest another term - perhaps CODE_BLOCK_HEADER_ARGUMENTS (plus an easy-template for easy insertion). Nick
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Nick Dokos nicholas.do...@hp.com writes: Eric Schulte schulte.e...@gmail.com wrote: I have just pushed up a change to the Org-mode git repository which removes support for #+BABEL lines. Please use the more general #+PROPERTIES lines instead. Coming late to the dance - sorry. I think that's very confusing. Property is an overloaded term in org: we now have the :PROPERTIES: drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and plural forms are already pretty bad). Do the #+PROPERTY and #+PROPERTIES lines have different semantics? Also, there is the general concept of properties (the stuff that the property API applies to). Unless there is an underlying unity of which I'm unaware, I'd strongly suggest another term - perhaps CODE_BLOCK_HEADER_ARGUMENTS (plus an easy-template for easy insertion). Code blocks already piggy-back off of subtree properties pulling their header arguments out of the properties specified on the subtree level. Given that header arguments and properties are already thus interleaved I believe that properties should be used on the file-wide level as well, rather than introducing another synonymous keyword which adds no new functionality. Does that make sense? Best -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Eric Schulte schulte.e...@gmail.com wrote: Nick Dokos nicholas.do...@hp.com writes: Eric Schulte schulte.e...@gmail.com wrote: I have just pushed up a change to the Org-mode git repository which removes support for #+BABEL lines. Please use the more general #+PROPERTIES lines instead. Coming late to the dance - sorry. I think that's very confusing. Property is an overloaded term in org: we now have the :PROPERTIES: drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and plural forms are already pretty bad). Do the #+PROPERTY and #+PROPERTIES lines have different semantics? I think so: see section 7.1 for a use of the former. AFAICT, the latter only applies to code block header arguments. Also, there is the general concept of properties (the stuff that the property API applies to). Unless there is an underlying unity of which I'm unaware, I'd strongly suggest another term - perhaps CODE_BLOCK_HEADER_ARGUMENTS (plus an easy-template for easy insertion). Code blocks already piggy-back off of subtree properties pulling their header arguments out of the properties specified on the subtree level. Given that header arguments and properties are already thus interleaved I believe that properties should be used on the file-wide level as well, rather than introducing another synonymous keyword which adds no new functionality. Does that make sense? Yes, but the #+PROPERTIES line has nothing to do with org properties. It *only* affects code blocks, no? Nick
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hi Nick and Eric, Nick Dokos wrote: Eric Schulte schulte.e...@gmail.com wrote: Nick Dokos nicholas.do...@hp.com writes: Eric Schulte schulte.e...@gmail.com wrote: I have just pushed up a change to the Org-mode git repository which removes support for #+BABEL lines. Please use the more general #+PROPERTIES lines instead. Coming late to the dance - sorry. I think that's very confusing. Property is an overloaded term in org: we now have the :PROPERTIES: drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and plural forms are already pretty bad). If you'd have asked me, I would have chosen #+BABEL instead of #+PROPERTIES, as it made it clear who owned those directives, to whom they were targeted. Do the #+PROPERTY and #+PROPERTIES lines have different semantics? I think so: see section 7.1 for a use of the former. AFAICT, the latter only applies to code block header arguments. Also, there is the general concept of properties (the stuff that the property API applies to). Unless there is an underlying unity of which I'm unaware, I'd strongly suggest another term - perhaps CODE_BLOCK_HEADER_ARGUMENTS (plus an easy-template for easy insertion). Code blocks already piggy-back off of subtree properties pulling their header arguments out of the properties specified on the subtree level. Given that header arguments and properties are already thus interleaved I believe that properties should be used on the file-wide level as well, rather than introducing another synonymous keyword which adds no new functionality. Does that make sense? However, I've been convinced by Eric's arguments. The fact you already can mix BABEL properties in subtree PROPERTIES... Yes, but the #+PROPERTIES line has nothing to do with org properties. It *only* affects code blocks, no? But, I guess you're right, Nick: not the other way around. So, I don't know anymore what to think... I do well agree that properties has not a clear-cut meaning anymore; this is a very general word. Now, if I had to choose between #+PROPERTY and #+PROPERTIES, I would favor the last one, as it is some place where you can stuff many properties -- and to reflect what's already use for the export options: there you put the options under the OPTIONS meta-keyword. In the plural form. Just my 2 cents. Whatever your choice, I'll follow it. And I always prefer to reduce the number of synonyms, and have just one official form[1]. Best regards, Seb Footnotes: [1] I have the same annoying feelings with #+SOURCE, #+SRCNAME, #+FUNCTION, #+CALL, #+LOB, and SBE, some of which are interchangeable; some not. I'd prefer deprecating an old form when a better one is found. -- Sebastien Vauban
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Whoa -- before this gets more confusing: Eric, did you push up a (new, or at least so far undocumented in the manual) syntax involving a #+PROPERTIES line, as Nick and Sebastien seem to understand you? Or was #+PROPERTIES just a typo, and you mean using the #+PROPERTY line or :PROPERTIES: drawer, as provided in the manual? Yours, Christian (lamenting the demise of the #+BABEL header I'd just recently started to use) On 10/20/11 10:12 PM, Eric Schulte wrote: Nick Dokosnicholas.do...@hp.com writes: Eric Schulteschulte.e...@gmail.com wrote: I have just pushed up a change to the Org-mode git repository which removes support for #+BABEL lines. Please use the more general #+PROPERTIES lines instead. Coming late to the dance - sorry. I think that's very confusing. Property is an overloaded term in org: we now have the :PROPERTIES: drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and plural forms are already pretty bad). Do the #+PROPERTY and #+PROPERTIES lines have different semantics? Also, there is the general concept of properties (the stuff that the property API applies to). Unless there is an underlying unity of which I'm unaware, I'd strongly suggest another term - perhaps CODE_BLOCK_HEADER_ARGUMENTS (plus an easy-template for easy insertion). Code blocks already piggy-back off of subtree properties pulling their header arguments out of the properties specified on the subtree level. Given that header arguments and properties are already thus interleaved I believe that properties should be used on the file-wide level as well, rather than introducing another synonymous keyword which adds no new functionality. Does that make sense? Best -- Eric
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Christian Moe m...@christianmoe.com wrote: Whoa -- before this gets more confusing: Eric, did you push up a (new, or at least so far undocumented in the manual) syntax involving a #+PROPERTIES line, as Nick and Sebastien seem to understand you? Or was #+PROPERTIES just a typo, and you mean using the #+PROPERTY line or :PROPERTIES: drawer, as provided in the manual? Here's the commit log (I think it reflects the code changes faithfully): , | commit 04a978fde525a442f9de14d1a67783edd5c9cb78 | Author: Eric Schulte schulte.e...@gmail.com | Date: Thu Oct 20 13:31:20 2011 -0600 | | removing #+BABEL: lines in favor of general #+PROPERTIES: lines | | * lisp/ob.el (org-babel-params-from-buffer): Removing #+BABEL: lines | in favor of general #+PROPERTIES: lines. | | * doc/org.texi (Buffer-wide header arguments): Removing documentation | of the defunct #+BABEL: structure. ` So #+BABEL was traded for #+PROPERTIES. Nick Yours, Christian (lamenting the demise of the #+BABEL header I'd just recently started to use) On 10/20/11 10:12 PM, Eric Schulte wrote: Nick Dokosnicholas.do...@hp.com writes: Eric Schulteschulte.e...@gmail.com wrote: I have just pushed up a change to the Org-mode git repository which removes support for #+BABEL lines. Please use the more general #+PROPERTIES lines instead. Coming late to the dance - sorry. I think that's very confusing. Property is an overloaded term in org: we now have the :PROPERTIES: drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and plural forms are already pretty bad). Do the #+PROPERTY and #+PROPERTIES lines have different semantics? Also, there is the general concept of properties (the stuff that the property API applies to). Unless there is an underlying unity of which I'm unaware, I'd strongly suggest another term - perhaps CODE_BLOCK_HEADER_ARGUMENTS (plus an easy-template for easy insertion). Code blocks already piggy-back off of subtree properties pulling their header arguments out of the properties specified on the subtree level. Given that header arguments and properties are already thus interleaved I believe that properties should be used on the file-wide level as well, rather than introducing another synonymous keyword which adds no new functionality. Does that make sense? Best -- Eric
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Nick Dokos nicholas.do...@hp.com writes: Eric Schulte schulte.e...@gmail.com wrote: Nick Dokos nicholas.do...@hp.com writes: Eric Schulte schulte.e...@gmail.com wrote: I have just pushed up a change to the Org-mode git repository which removes support for #+BABEL lines. Please use the more general #+PROPERTIES lines instead. Coming late to the dance - sorry. I think that's very confusing. Property is an overloaded term in org: we now have the :PROPERTIES: drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and plural forms are already pretty bad). Do the #+PROPERTY and #+PROPERTIES lines have different semantics? I think so: see section 7.1 for a use of the former. AFAICT, the latter only applies to code block header arguments. Oh! Thank you for making this clear, I had assumed that #+PROPERTIES: lines were an integral part of Org-mode which code block header arguments were simply making use of. Having read the section of the info manual you point out above I see that I was mistaken. I've just pushed up what I consider to be a clean implementation. Put briefly the new behavior is that properties may be used to specify header arguments. More completely... 1. The #+PROPERTIES: (and #+BABEL:) directives no longer exist. 2. The existing #+PROPERTY: line may now be used to specify values for header arguments, e.g., #+PROPERTY: results silent would silence all results in the current buffer. I think this should be simple, easy to remember, and it certainly cleaned up the code base. Please let me know what you think of this new setup. Thanks -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hi Eric, On Thu, Oct 20, 2011 at 11:34 PM, Eric Schulte schulte.e...@gmail.com wrote: 2. The existing #+PROPERTY: line may now be used to specify values for header arguments, e.g., #+PROPERTY: results silent would silence all results in the current buffer. Is the 'results' without a preceding colon or is that a typo? -- Suvayu Open source is the future. It sets us free.
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hi Eric, Eric Schulte wrote: Nick Dokos nicholas.do...@hp.com writes: Eric Schulte schulte.e...@gmail.com wrote: Nick Dokos nicholas.do...@hp.com writes: Eric Schulte schulte.e...@gmail.com wrote: I have just pushed up a change to the Org-mode git repository which removes support for #+BABEL lines. Please use the more general #+PROPERTIES lines instead. Coming late to the dance - sorry. I think that's very confusing. Property is an overloaded term in org: we now have the :PROPERTIES: drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and plural forms are already pretty bad). Do the #+PROPERTY and #+PROPERTIES lines have different semantics? I think so: see section 7.1 for a use of the former. AFAICT, the latter only applies to code block header arguments. Oh! Thank you for making this clear, I had assumed that #+PROPERTIES: lines were an integral part of Org-mode which code block header arguments were simply making use of. Having read the section of the info manual you point out above I see that I was mistaken. I've just pushed up what I consider to be a clean implementation. Put briefly the new behavior is that properties may be used to specify header arguments. More completely... 1. The #+PROPERTIES: (and #+BABEL:) directives no longer exist. 2. The existing #+PROPERTY: line may now be used to specify values for header arguments, e.g., #+PROPERTY: results silent would silence all results in the current buffer. I think this should be simple, easy to remember, and it certainly cleaned up the code base. Please let me know what you think of this new setup. I just have one question, as I'm puzzled by the lack of `:' in front of the properties: how do we distinguish the argument value from the argument name? For example, how do we translate, in the new syntax, #+BABEL::results output code append (where `:results' is the name, and `output', `code' and `append' are values)? Best regards, Seb -- Sebastien Vauban
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Eric Schulte schulte.e...@gmail.com wrote: ... I've just pushed up what I consider to be a clean implementation. Put briefly the new behavior is that properties may be used to specify header arguments. More completely... 1. The #+PROPERTIES: (and #+BABEL:) directives no longer exist. 2. The existing #+PROPERTY: line may now be used to specify values for header arguments, e.g., #+PROPERTY: results silent would silence all results in the current buffer. I think this should be simple, easy to remember, and it certainly cleaned up the code base. Please let me know what you think of this new setup. Other than colon confusion (having to specify ``:results silent'' on the src block header line and ``results silent'' in the #+PROPERTY line to get the same behavior), this looks better. Not sure what (if anything) can or should be done about the colons. Thanks, Nick
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
suvayu ali fatkasuvayu+li...@gmail.com writes: Hi Eric, On Thu, Oct 20, 2011 at 11:34 PM, Eric Schulte schulte.e...@gmail.com wrote: 2. The existing #+PROPERTY: line may now be used to specify values for header arguments, e.g., #+PROPERTY: results silent would silence all results in the current buffer. Is the 'results' without a preceding colon or is that a typo? As with properties specified in :PROPERTIES: blocks under headlines, the colon is not needed, the above is correct. Best -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Eric, Eric Schulte wrote: Nick Dokos nicholas.do...@hp.com writes: Eric Schulte schulte.e...@gmail.com wrote: Nick Dokos nicholas.do...@hp.com writes: Eric Schulte schulte.e...@gmail.com wrote: I have just pushed up a change to the Org-mode git repository which removes support for #+BABEL lines. Please use the more general #+PROPERTIES lines instead. Coming late to the dance - sorry. I think that's very confusing. Property is an overloaded term in org: we now have the :PROPERTIES: drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and plural forms are already pretty bad). Do the #+PROPERTY and #+PROPERTIES lines have different semantics? I think so: see section 7.1 for a use of the former. AFAICT, the latter only applies to code block header arguments. Oh! Thank you for making this clear, I had assumed that #+PROPERTIES: lines were an integral part of Org-mode which code block header arguments were simply making use of. Having read the section of the info manual you point out above I see that I was mistaken. I've just pushed up what I consider to be a clean implementation. Put briefly the new behavior is that properties may be used to specify header arguments. More completely... 1. The #+PROPERTIES: (and #+BABEL:) directives no longer exist. 2. The existing #+PROPERTY: line may now be used to specify values for header arguments, e.g., #+PROPERTY: results silent would silence all results in the current buffer. I think this should be simple, easy to remember, and it certainly cleaned up the code base. Please let me know what you think of this new setup. I just have one question, as I'm puzzled by the lack of `:' in front of the properties: how do we distinguish the argument value from the argument name? For example, how do we translate, in the new syntax, #+BABEL::results output code append (where `:results' is the name, and `output', `code' and `append' are values)? The above would become #+PROPERTY: results output code append Since only one property may be specified per property line there is no need for colons. This mirrors exactly the way the properties are saved under subtrees in :PROPERTY: blocks. Multiple lines may be used to specify multiple properties. e.g., #+PROPERTY: results silent #+PROPERTY: cache yes Best -- Eric Best regards, Seb -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Sebastien Vauban wxhgmqzgw...@spammotel.com wrote: I just have one question, as I'm puzzled by the lack of `:' in front of the properties: how do we distinguish the argument value from the argument name? For example, how do we translate, in the new syntax, #+BABEL::results output code append (where `:results' is the name, and `output', `code' and `append' are values)? #+PROPERTY: results output code append See the aforementioned sec. 7.1 of the manual. Equivalently, * foo :PROPERTIES: :results: output code append :END: That's a consequence of the property syntax. On the code block header line however, you have to have some purely syntactic marker to distinguish properties from their values, hence #+begin_src foo :results output code append :exports both ... The trick is to think of the colon as a delimited (like a comma) not as a part of the property name. Nick
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Nick Dokos nicholas.do...@hp.com writes: Eric Schulte schulte.e...@gmail.com wrote: ... I've just pushed up what I consider to be a clean implementation. Put briefly the new behavior is that properties may be used to specify header arguments. More completely... 1. The #+PROPERTIES: (and #+BABEL:) directives no longer exist. 2. The existing #+PROPERTY: line may now be used to specify values for header arguments, e.g., #+PROPERTY: results silent would silence all results in the current buffer. I think this should be simple, easy to remember, and it certainly cleaned up the code base. Please let me know what you think of this new setup. Other than colon confusion (having to specify ``:results silent'' on the src block header line and ``results silent'' in the #+PROPERTY line to get the same behavior), this looks better. Not sure what (if anything) can or should be done about the colons. I don't know of a good solution for colons. If we decided to add colons then the subtree property blocks would become akward, with entries like ** foo :PROPERTIES: ::results: silent :END: I would say we could look for each value both with and without colons, but property searches of this nature are slow and doubling the speed impact simply for allow colon flexibility doesn't seem to be a good tradeoff. I think this will just have to be something that users will need to learn. Cheers -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Eric Schulte schulte.e...@gmail.com wrote: Other than colon confusion (having to specify ``:results silent'' on the src block header line and ``results silent'' in the #+PROPERTY line to get the same behavior), this looks better. Not sure what (if anything) can or should be done about the colons. I don't know of a good solution for colons. If we decided to add colons then the subtree property blocks would become akward, with entries like ** foo :PROPERTIES: ::results: silent :END: I would say we could look for each value both with and without colons, but property searches of this nature are slow and doubling the speed impact simply for allow colon flexibility doesn't seem to be a good tradeoff. I think this will just have to be something that users will need to learn. I agree[fn:1]: the point is to simplify the code, not complicate it *and* slow down everything at the same time. Maybe the header args section of the manual can use the colon as delimiter method to explain the equivalent forms and that will suffice. Nick Footnotes: [fn:1] ...but I take some perverse pleasure from the fact that both Suvayu and Seb asked the question :-)
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Nick Dokos nicholas.do...@hp.com writes: Eric Schulte schulte.e...@gmail.com wrote: Other than colon confusion (having to specify ``:results silent'' on the src block header line and ``results silent'' in the #+PROPERTY line to get the same behavior), this looks better. Not sure what (if anything) can or should be done about the colons. I don't know of a good solution for colons. If we decided to add colons then the subtree property blocks would become akward, with entries like ** foo :PROPERTIES: ::results: silent :END: I would say we could look for each value both with and without colons, but property searches of this nature are slow and doubling the speed impact simply for allow colon flexibility doesn't seem to be a good tradeoff. I think this will just have to be something that users will need to learn. I agree[fn:1]: the point is to simplify the code, not complicate it *and* slow down everything at the same time. Maybe the header args section of the manual can use the colon as delimiter method to explain the equivalent forms and that will suffice. I agree, the header argument syntax portion of the documentation could be made more clear, and I did like you explanation to Seb's email. Perhaps you could submit a documentation patch? :) Nick Footnotes: [fn:1] ...but I take some perverse pleasure from the fact that both Suvayu and Seb asked the question :-) I noticed that too, and it no doubt means that this same question will occur to future users. -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On Thu, 20 Oct 2011 15:52:42 -0600 Eric Schulte schulte.e...@gmail.com wrote: suvayu ali fatkasuvayu+li...@gmail.com writes: Hi Eric, On Thu, Oct 20, 2011 at 11:34 PM, Eric Schulte schulte.e...@gmail.com wrote: 2. The existing #+PROPERTY: line may now be used to specify values for header arguments, e.g., #+PROPERTY: results silent would silence all results in the current buffer. Is the 'results' without a preceding colon or is that a typo? As with properties specified in :PROPERTIES: blocks under headlines, the colon is not needed, the above is correct. Thanks a lot Eric. I have never used :PROPERTIES: for Babel, hence I didn't know! Best -- Eric Cheers, -- Suvayu Open source is the future. It sets us free.
