Re: [O] About commit named Allow multi-line properties to be specified in property blocks
Is that patch on git yet? i.e. if can I switch back to HEAD and change my files accordingly? Cheers, Rainer On Wed, Nov 9, 2011 at 11:31 PM, Sebastien Vauban wxhgmqzgw...@spammotel.com wrote: Hi Eric, Eric Schulte wrote: Rainer M Krug r.m.k...@gmail.com writes: On Tue, Nov 8, 2011 at 11:53 PM, Eric Schulte schulte.e...@gmail.com wrote: Perhaps inserting an assumed space separator would be more intuitive? If we were to go that way it may be possible to allow variable specifications such as #+PROPERTY: var foo=1 bar=2 in which case properties could be easily specified on multiple lines using a default space separator. If this seems like a good way to go I can try to update my previous patch. I've updated the patch, the newest version is attached. It results in the following behavior. Looks good to me - that leaves just the question, what would hppen when doing the following: #+property: var foo=1 #+property: var+ 2 The above is equivalent to, #+header: :var foo=1 2 which due to interaction with some logic put in place to allow the specification of un-named variables in call lines results in the following. #+property: var foo=1 #+property: var+ 2 #+begin_src emacs-lisp foo #+end_src #+results: : 2 #+begin_src emacs-lisp :var bar=1 2 bar #+end_src #+results: : 2 Although generally I would say that both #+header: :var foo=1 2 and #+property: var foo=1 #+property: var+ 2 are mal-formed variable assignments. I was amazed, yesterday, when you told about `foo' becoming `12' (with `1' on the assignment line and `2' on the continuation), but I'm glad you consider this as rather ill-formed. and #+property: var foo=Hello #+property: var+ world This is exactly analogous to #+header: :var foo=hello world which raises the expected error ``variable world must be assigned a default value'' the following alternative however works as expected #+property: var foo=Hello #+property: var+ world #+begin_src emacs-lisp foo #+end_src #+results: : Hello world That said, all of these seem excellent trade-off between the different alternatives that have been discussed and analyzed, and they respect important aspects: simplicity (intuitive on reading) and powerfulness. Just perfect! 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] About commit named Allow multi-line properties to be specified in property blocks
Torsten Wagner torsten.wag...@gmail.com writes: Hi, Eric I lost a bit track of what was the final decsion. Guess a good way to get back on track would be helping with the documentary. Any tasks to do? Tom has handled the documentation (thanks Tom!) so he would know better than I if there are any outstanding documentation tasks. As a means of catching up with the final decisions I would recommend reviewing the two commit messages linked to from my email this morning announcing the merge. Another task which would be much appreciated would be to go through the introduction to working with code blocks on Worg and update the syntax as appropriate. http://orgmode.org/worg/org-contrib/babel/intro.html Thanks for the offer! -- Eric Torsten -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
Aloha Torsten, Let me clean up some loose ends in the documentation of standardized keywords in org.texi later today. Eric moves more quickly than I do and the documentation is in a working draft stage, definitely not ready for consumption and use. I didn't get around to documenting the ability to accumulate properties, so please have a go at that if you like. I looked at it briefly and thought that there should be an overview of the new functionality in section 7.1, after the discussion of _ALL properties, and then details in the section on Working with Source Code, where use of the functionality with var=name should be explained. I'm not too clear on the other possibilities this functionality introduces, so my ideas here might be wide of the mark. All the best, Tom Eric Schulte schulte.e...@gmail.com writes: Torsten Wagner torsten.wag...@gmail.com writes: Hi, Eric I lost a bit track of what was the final decsion. Guess a good way to get back on track would be helping with the documentary. Any tasks to do? Tom has handled the documentation (thanks Tom!) so he would know better than I if there are any outstanding documentation tasks. As a means of catching up with the final decisions I would recommend reviewing the two commit messages linked to from my email this morning announcing the merge. Another task which would be much appreciated would be to go through the introduction to working with code blocks on Worg and update the syntax as appropriate. http://orgmode.org/worg/org-contrib/babel/intro.html Thanks for the offer! -- Eric Torsten -- Thomas S. Dye http://www.tsdye.com
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
On Tue, Nov 15, 2011 at 5:00 PM, Eric Schulte schulte.e...@gmail.comwrote: Rainer M Krug r.m.k...@gmail.com writes: Is that patch on git yet? i.e. if can I switch back to HEAD and change my files accordingly? Hi Rainer, I've must merged all of the pending code block changes into the master branch of the Org-mode git repository. So now would be a good time to re-sync with the master branch. Great news. I'll try and adapt my files then tomorrow and let you know if there are any problems. Thanks, Rainer Best -- Eric Cheers, Rainer On Wed, Nov 9, 2011 at 11:31 PM, Sebastien Vauban wxhgmqzgw...@spammotel.com wrote: Hi Eric, Eric Schulte wrote: Rainer M Krug r.m.k...@gmail.com writes: On Tue, Nov 8, 2011 at 11:53 PM, Eric Schulte schulte.e...@gmail.com wrote: Perhaps inserting an assumed space separator would be more intuitive? If we were to go that way it may be possible to allow variable specifications such as #+PROPERTY: var foo=1 bar=2 in which case properties could be easily specified on multiple lines using a default space separator. If this seems like a good way to go I can try to update my previous patch. I've updated the patch, the newest version is attached. It results in the following behavior. Looks good to me - that leaves just the question, what would hppen when doing the following: #+property: var foo=1 #+property: var+ 2 The above is equivalent to, #+header: :var foo=1 2 which due to interaction with some logic put in place to allow the specification of un-named variables in call lines results in the following. #+property: var foo=1 #+property: var+ 2 #+begin_src emacs-lisp foo #+end_src #+results: : 2 #+begin_src emacs-lisp :var bar=1 2 bar #+end_src #+results: : 2 Although generally I would say that both #+header: :var foo=1 2 and #+property: var foo=1 #+property: var+ 2 are mal-formed variable assignments. I was amazed, yesterday, when you told about `foo' becoming `12' (with `1' on the assignment line and `2' on the continuation), but I'm glad you consider this as rather ill-formed. and #+property: var foo=Hello #+property: var+ world This is exactly analogous to #+header: :var foo=hello world which raises the expected error ``variable world must be assigned a default value'' the following alternative however works as expected #+property: var foo=Hello #+property: var+ world #+begin_src emacs-lisp foo #+end_src #+results: : Hello world That said, all of these seem excellent trade-off between the different alternatives that have been discussed and analyzed, and they respect important aspects: simplicity (intuitive on reading) and powerfulness. Just perfect! Best regards, Seb -- Sebastien Vauban -- 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] About commit named Allow multi-line properties to be specified in property blocks
The cleaning up documentation patch has now been applied. Best -- Eric t...@tsdye.com (Thomas S. Dye) writes: Aloha Torsten, Let me clean up some loose ends in the documentation of standardized keywords in org.texi later today. Eric moves more quickly than I do and the documentation is in a working draft stage, definitely not ready for consumption and use. I didn't get around to documenting the ability to accumulate properties, so please have a go at that if you like. I looked at it briefly and thought that there should be an overview of the new functionality in section 7.1, after the discussion of _ALL properties, and then details in the section on Working with Source Code, where use of the functionality with var=name should be explained. I'm not too clear on the other possibilities this functionality introduces, so my ideas here might be wide of the mark. All the best, Tom Eric Schulte schulte.e...@gmail.com writes: Torsten Wagner torsten.wag...@gmail.com writes: Hi, Eric I lost a bit track of what was the final decsion. Guess a good way to get back on track would be helping with the documentary. Any tasks to do? Tom has handled the documentation (thanks Tom!) so he would know better than I if there are any outstanding documentation tasks. As a means of catching up with the final decisions I would recommend reviewing the two commit messages linked to from my email this morning announcing the merge. Another task which would be much appreciated would be to go through the introduction to working with code blocks on Worg and update the syntax as appropriate. http://orgmode.org/worg/org-contrib/babel/intro.html Thanks for the offer! -- Eric Torsten -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
On Tue, Nov 8, 2011 at 11:53 PM, Eric Schulte schulte.e...@gmail.comwrote: Perhaps inserting an assumed space separator would be more intuitive? If we were to go that way it may be possible to allow variable specifications such as #+PROPERTY: var foo=1 bar=2 in which case properties could be easily specified on multiple lines using a default space separator. If this seems like a good way to go I can try to update my previous patch. I've updated the patch, the newest version is attached. It results in the following behavior. Looks good to me - that leaves just the question, what would hppen when doing the following: #+property: var foo=1 #+property: var+ 2 and #+property: var foo=Hello #+property: var+ world Thanks, Rainer -- 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] About commit named Allow multi-line properties to be specified in property blocks
Rainer M Krug r.m.k...@gmail.com writes: On Tue, Nov 8, 2011 at 11:53 PM, Eric Schulte schulte.e...@gmail.comwrote: Perhaps inserting an assumed space separator would be more intuitive? If we were to go that way it may be possible to allow variable specifications such as #+PROPERTY: var foo=1 bar=2 in which case properties could be easily specified on multiple lines using a default space separator. If this seems like a good way to go I can try to update my previous patch. I've updated the patch, the newest version is attached. It results in the following behavior. Looks good to me - that leaves just the question, what would hppen when doing the following: #+property: var foo=1 #+property: var+ 2 The above is equivalent to, #+header: :var foo=1 2 which due to interaction with some logic put in place to allow the specification of un-named variables in call lines results in the following. #+property: var foo=1 #+property: var+ 2 #+begin_src emacs-lisp foo #+end_src #+results: : 2 #+begin_src emacs-lisp :var bar=1 2 bar #+end_src #+results: : 2 Although generally I would say that both #+header: :var foo=1 2 and #+property: var foo=1 #+property: var+ 2 are mal-formed variable assignments. and #+property: var foo=Hello #+property: var+ world This is exactly analogous to #+header: :var foo=hello world which raises the expected error ``variable world must be assigned a default value'' the following alternative however works as expected #+property: var foo=Hello #+property: var+ world #+begin_src emacs-lisp foo #+end_src #+results: : Hello world Thanks for these examples, the later did brought to light a small quoting issue which is fixed in the new attached patch. Best -- Eric From 3be23a3631d108e19d2b8d781077130f1e12bb19 Mon Sep 17 00:00:00 2001 From: Eric Schulte schulte.e...@gmail.com Date: Mon, 7 Nov 2011 14:49:42 -0700 Subject: [PATCH] property names ending in plus accumulate This results in the following behavior. #+property: var foo=1 #+property: var+ bar=2 #+begin_src emacs-lisp (+ foo bar) #+end_src #+results: : 3 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=1 bar=2 * overwriting a file-wide property :PROPERTIES: :var: foo=7 :END: #+begin_src emacs-lisp foo #+end_src #+results: : 7 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=7 * appending to a file-wide property :PROPERTIES: :var+: baz=3 :END: #+begin_src emacs-lisp (+ foo bar baz) #+end_src #+results: : 6 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=1 bar=2 baz=3 * lisp/org.el (org-update-property-plist): Updates a given property list with a property name and a property value. (org-set-regexps-and-options): Use org-update-property-plist. (org-entry-get): Use org-update-property-plist. * testing/examples/property-inheritance.org: Example file for testing appending property behavior. * testing/lisp/test-property-inheritance.el: Tests of appending property behavior. * lisp/ob.el (org-babel-balanced-split): Allow splitting on single characters as well as groups of two characters. (org-babel-parse-multiple-vars): Split variables on single spaces. --- lisp/ob.el| 21 +++--- lisp/org.el | 47 +++--- testing/examples/property-inheritance.org | 36 + testing/lisp/test-property-inheritance.el | 61 + 4 files changed, 143 insertions(+), 22 deletions(-) create mode 100644 testing/examples/property-inheritance.org create mode 100644 testing/lisp/test-property-inheritance.el diff --git a/lisp/ob.el b/lisp/ob.el index d94b4b6..51ae9c4 100644 --- a/lisp/ob.el +++ b/lisp/ob.el @@ -1118,17 +1118,24 @@ instances of \[ \t]:\ set ALTS to '((32 9) . 58). (flet ((matches (ch spec) (or (and (numberp spec) (= spec ch)) (member ch spec))) (matched (ch last) - (and (matches ch (cdr alts)) - (matches last (car alts) -(let ((balance 0) (partial nil) (lst nil) (last 0)) - (mapc (lambda (ch) ; split on [] or () balanced instances of [ \t]: + (if (consp alts) + (and (matches ch (cdr alts)) + (matches last (car alts))) + (matches ch alts +(let ((balance 0) (quote nil) (partial nil) (lst nil) (last 0)) + (mapc (lambda (ch) ; split on [], (), balanced instances of [ \t]: (setq balance (+ balance (cond ((or (equal 91 ch) (equal 40 ch)) 1) ((or (equal 93 ch) (equal 41 ch)) -1) (t 0 + (when (and (equal 34 ch) (not (equal 92 last))) + (setq quote (not quote))) (setq partial (cons ch partial)) - (when (and (= balance 0) (matched ch last)) - (setq lst (cons (apply #'string (nreverse (cddr
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
On Wed, Nov 9, 2011 at 5:12 PM, Eric Schulte schulte.e...@gmail.com wrote: Rainer M Krug r.m.k...@gmail.com writes: On Tue, Nov 8, 2011 at 11:53 PM, Eric Schulte schulte.e...@gmail.com wrote: Perhaps inserting an assumed space separator would be more intuitive? If we were to go that way it may be possible to allow variable specifications such as #+PROPERTY: var foo=1 bar=2 in which case properties could be easily specified on multiple lines using a default space separator. If this seems like a good way to go I can try to update my previous patch. I've updated the patch, the newest version is attached. It results in the following behavior. Looks good to me - that leaves just the question, what would hppen when doing the following: #+property: var foo=1 #+property: var+ 2 The above is equivalent to, #+header: :var foo=1 2 which due to interaction with some logic put in place to allow the specification of un-named variables in call lines results in the following. #+property: var foo=1 #+property: var+ 2 #+begin_src emacs-lisp foo #+end_src #+results: : 2 #+begin_src emacs-lisp :var bar=1 2 bar #+end_src #+results: : 2 Although generally I would say that both #+header: :var foo=1 2 and #+property: var foo=1 #+property: var+ 2 are mal-formed variable assignments. True. and #+property: var foo=Hello #+property: var+ world This is exactly analogous to #+header: :var foo=hello world Makes sense which raises the expected error ``variable world must be assigned a default value'' the following alternative however works as expected #+property: var foo=Hello #+property: var+ world #+begin_src emacs-lisp foo #+end_src #+results: : Hello world Lovely - so I can break longer string characters in multiple lines - brilliant. Thanks for these examples, the later did brought to light a small quoting issue which is fixed in the new attached patch. Best -- Eric Thanks, Rainer -- Eric Schulte http://cs.unm.edu/~eschulte/ -- 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] About commit named Allow multi-line properties to be specified in property blocks
Hi Eric, On 2011-11-03, Eric Schulte schulte.e...@gmail.com wrote: But allowing a top-level :PROPERTIES: drawer with properties whose scope is the entire file looks like a good idea to me. I don't see what this would add, how would this solve the need for multi-line properties, and how would it differ from IMO being uglier than a series of #+PROPERTY: lines. (Your quote is from Bastien, not me.) The idea the way I put it (which is with a top level entry to hold the properties drawer) is, as I stated, possibly too radical for the thread. Possibly too radical period. So feel free to ignore it. However, let me clarify because I think you might misunderstand. The idea is not to augment syntax, but reduce it. Or, if backward compatibility is desired, then reduce the need for future ambiguous-scope syntax -- which is a currently unresolved problem. In my view #+ is uglier than existing property syntax -- which has to exist anyway because it is used for all sorts of things. You can't get rid of it. (And shouldn't.) The idea is that a single top-level task, marked as such, acts as if it were a superlevel, and contains ALL information needed for the file level. So there will be no need for #+property . It is consistent syntax with the rest of Org, unlike file-level or rest-of-file #+ syntax. It is less ambiguous in scope. It is clear what it means. It is foldable. It is searchable the same way other entries are searchable. The agenda can show it if you want it to (unlike #+whatever). More consistent all the way around IMO. If I were designing Org from scratch, I probably would not suggest this. Instead, I would simply disallow file-level anything. If you want that, just use a top-level task. a/b/c -- you know, normal outline. And then export that top level subtree. To me, and this is admittedly radical, file-level operations should be deprecated. But as a compromise, since a lot of people do file-level operations, I am proposing a dedicated top level place that acts as if it is hierarchically above everything else even though it is not. That allows consistency better than #+property IMO. I am talking about the stuff at the top of the file (title, properties, etc.) Not blocks etc. Those are reasonable elsewhere. As for multiple-line properties, you can use the syntax you're currently discussing to accumulate in the properties drawer, or even use a syntax to simply allow multiple-line properties in a properties drawer. Either way. Again, probably too radical for this thread, but I wanted to clarify. Hope that clarifies. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com === Bigotry against people with serious diseases is still bigotry.
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
Hi Eric, Eric Schulte wrote: Rainer M Krug r.m.k...@gmail.com writes: On Tue, Nov 8, 2011 at 11:53 PM, Eric Schulte schulte.e...@gmail.comwrote: Perhaps inserting an assumed space separator would be more intuitive? If we were to go that way it may be possible to allow variable specifications such as #+PROPERTY: var foo=1 bar=2 in which case properties could be easily specified on multiple lines using a default space separator. If this seems like a good way to go I can try to update my previous patch. I've updated the patch, the newest version is attached. It results in the following behavior. Looks good to me - that leaves just the question, what would hppen when doing the following: #+property: var foo=1 #+property: var+ 2 The above is equivalent to, #+header: :var foo=1 2 which due to interaction with some logic put in place to allow the specification of un-named variables in call lines results in the following. #+property: var foo=1 #+property: var+ 2 #+begin_src emacs-lisp foo #+end_src #+results: : 2 #+begin_src emacs-lisp :var bar=1 2 bar #+end_src #+results: : 2 Although generally I would say that both #+header: :var foo=1 2 and #+property: var foo=1 #+property: var+ 2 are mal-formed variable assignments. I was amazed, yesterday, when you told about `foo' becoming `12' (with `1' on the assignment line and `2' on the continuation), but I'm glad you consider this as rather ill-formed. and #+property: var foo=Hello #+property: var+ world This is exactly analogous to #+header: :var foo=hello world which raises the expected error ``variable world must be assigned a default value'' the following alternative however works as expected #+property: var foo=Hello #+property: var+ world #+begin_src emacs-lisp foo #+end_src #+results: : Hello world That said, all of these seem excellent trade-off between the different alternatives that have been discussed and analyzed, and they respect important aspects: simplicity (intuitive on reading) and powerfulness. Just perfect! Best regards, Seb -- Sebastien Vauban
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
On Mon, Nov 7, 2011 at 11:09 PM, Eric Schulte schulte.e...@gmail.comwrote: The attached patch implements this latest propname+ suggestion. When applied it results in the behavior shown below. I'm inclined to go with this as a solution moving forward. Thoughts? Go for it - looks like a really good way of doing it. Cheers, Rainer -- 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] About commit named Allow multi-line properties to be specified in property blocks
Hi Eric, (Due to a high buzyness level, I've been a bit out of the discussion for one week or so) Eric Schulte wrote: The attached patch implements this latest propname+ suggestion. When applied it results in the behavior shown below. I'm inclined to go with this as a solution moving forward. Thoughts? #+property: varfoo=1 #+property: var+ , bar=2 #+begin_src emacs-lisp (+ foo bar) #+end_src So, in a way, adding the + after `var' is how you tell Org that this is an accumulated property? Two questions: 1. Why not the + after the property keyword (property+)? I guess because it's more against other aspects of Org internals? Anyway, putting + after the var sounds as right to me -- maybe better even if we consider that you declare var as accumulated, writing so. 2. Must there be a first `var' without `+'? Accepted, tolerated or wrong? I mean, I'm sure that, due to heavy file editing, we'll sometimes have: #+property: var+ foo=1 #+property: var+ , bar=2 #+begin_src emacs-lisp (+ foo bar) #+end_src #+results: : 3 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=1, bar=2 * overwriting a file-wide property :PROPERTIES: :var: foo=7 :END: #+begin_src emacs-lisp foo #+end_src #+results: : 7 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=7 * appending to a file-wide property :PROPERTIES: :var+: , baz=3 :END: To be honest, the only thing that I dislike is the comma in the above line. Not intuitive at all. Quite hard to read. Can't the comma be implicitly added by the `+' after the property name? That would allow one to simply write: * appending to a file-wide property :PROPERTIES: :var+:baz=3 :END: and have the correct values. #+begin_src emacs-lisp (+ foo bar baz) #+end_src #+results: : 6 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=1, bar=2, baz=3 Thanks. Best regards, Seb -- Sebastien Vauban
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
On Tue, Nov 8, 2011 at 10:31 AM, Sebastien Vauban wxhgmqzgw...@spammotel.com wrote: Hi Eric, (Due to a high buzyness level, I've been a bit out of the discussion for one week or so) Eric Schulte wrote: The attached patch implements this latest propname+ suggestion. When applied it results in the behavior shown below. I'm inclined to go with this as a solution moving forward. Thoughts? #+property: varfoo=1 #+property: var+ , bar=2 #+begin_src emacs-lisp (+ foo bar) #+end_src So, in a way, adding the + after `var' is how you tell Org that this is an accumulated property? Two questions: 1. Why not the + after the property keyword (property+)? I guess because it's more against other aspects of Org internals? Anyway, putting + after the var sounds as right to me -- maybe better even if we consider that you declare var as accumulated, writing so. 2. Must there be a first `var' without `+'? Accepted, tolerated or wrong? I mean, I'm sure that, due to heavy file editing, we'll sometimes have: Might be a good idea to tolerate this. #+property: var+ foo=1 #+property: var+ , bar=2 #+begin_src emacs-lisp (+ foo bar) #+end_src #+results: : 3 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=1, bar=2 * overwriting a file-wide property :PROPERTIES: :var: foo=7 :END: #+begin_src emacs-lisp foo #+end_src #+results: : 7 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=7 * appending to a file-wide property :PROPERTIES: :var+: , baz=3 :END: To be honest, the only thing that I dislike is the comma in the above line. Not intuitive at all. Quite hard to read. Can't the comma be implicitly added by the `+' after the property name? On the one hand, it might have one additional advantage: #+property: var foo=This is a very long text #+property: var+ with even more. Would foo be: This is a very long text with even more Could one make the , implicit, if the value follows the x=y style, while otherwise just concatenate the value to the one before? That would allow one to simply write: * appending to a file-wide property :PROPERTIES: :var+:baz=3 :END: and have the correct values. #+begin_src emacs-lisp (+ foo bar baz) #+end_src #+results: : 6 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=1, bar=2, baz=3 Thanks. 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] About commit named Allow multi-line properties to be specified in property blocks
Hi Rainer, Rainer M Krug wrote: The proposal is, when a property name ends in +, the value is appended to the corresponding property, rather than replacing it, so #+PROPERTY: var foo=1 #+PROPERTY: var bar=2 results in '((var . bar=2)) #+PROPERTY: varfoo=1 #+PROPERTY: var+ , bar=2 results in '((var . foo=1, bar=2)) This way subtree properties could be used as well, e.g., #+PROPERTY: var foo=1 * subtree :PROPERTIES: :var+: bar=2 :CUSTOM_ID: something :END: I like that suggestion - it is clear, easy to understand, gives other advantages (you can unset variables in a subtree - which would be an added bonus) and does not require any large changes in org files. How do you unset a var? By resetting the list with a new var (without `+'), and adding all the other valid vars? If so, not really unsetting... You simply void all vars, and create new definitions... Best regards, Seb -- Sebastien Vauban
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
On Tue, Nov 8, 2011 at 10:41 AM, Sebastien Vauban wxhgmqzgw...@spammotel.com wrote: Hi Rainer, Rainer M Krug wrote: The proposal is, when a property name ends in +, the value is appended to the corresponding property, rather than replacing it, so #+PROPERTY: var foo=1 #+PROPERTY: var bar=2 results in '((var . bar=2)) #+PROPERTY: varfoo=1 #+PROPERTY: var+ , bar=2 results in '((var . foo=1, bar=2)) This way subtree properties could be used as well, e.g., #+PROPERTY: var foo=1 * subtree :PROPERTIES: :var+: bar=2 :CUSTOM_ID: something :END: I like that suggestion - it is clear, easy to understand, gives other advantages (you can unset variables in a subtree - which would be an added bonus) and does not require any large changes in org files. How do you unset a var? By resetting the list with a new var (without `+'), and adding all the other valid vars? If so, not really unsetting... You simply void all vars, and create new definitions... Exactly - with unseting var, I don't refer to unsetting a single variable, but all variables. But as we have the var+, what about a var- to unset a single variable? 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] About commit named Allow multi-line properties to be specified in property blocks
Hi Rainer, Rainer M Krug wrote: * appending to a file-wide property :PROPERTIES: :var+: , baz=3 :END: To be honest, the only thing that I dislike is the comma in the above line. Not intuitive at all. Quite hard to read. Can't the comma be implicitly added by the `+' after the property name? On the one hand, it might have one additional advantage: #+property: var foo=This is a very long text #+property: var+ with even more. I don't think such a construction would be tolerated. I guess you must write a var name (foo, bar, baz, ...) after the `var+' keyword. Would foo be: This is a very long text with even more To be accurate, it would have become: This is a very long textwith even more if such a concatenation would be implied. Could one make the , implicit, if the value follows the x=y style, while otherwise just concatenate the value to the one before? I guess this is going too far, as Babel is untyped: what about... #+property: var foo=2 #+property: var+ 5 Does foo become equal to 25? (I know I exaggerate somehow, but just to show I guess such extensions are simply not possible without explicit types). But, if not equal to 25, what would be expected? An error, ...? Best regards, Seb -- Sebastien Vauban
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
On Tue, Nov 8, 2011 at 10:58 AM, Sebastien Vauban wxhgmqzgw...@spammotel.com wrote: Hi Rainer, Rainer M Krug wrote: * appending to a file-wide property :PROPERTIES: :var+: , baz=3 :END: To be honest, the only thing that I dislike is the comma in the above line. Not intuitive at all. Quite hard to read. Can't the comma be implicitly added by the `+' after the property name? On the one hand, it might have one additional advantage: #+property: var foo=This is a very long text #+property: var+ with even more. I don't think such a construction would be tolerated. I guess you must write a var name (foo, bar, baz, ...) after the `var+' keyword. Would foo be: This is a very long text with even more To be accurate, it would have become: This is a very long textwith even more if such a concatenation would be implied. Correct - missing space. Could one make the , implicit, if the value follows the x=y style, while otherwise just concatenate the value to the one before? I guess this is going too far, as Babel is untyped: what about... #+property: var foo=2 #+property: var+ 5 Does foo become equal to 25? (I know I exaggerate somehow, but just to show I guess such extensions are simply not possible without explicit types). You definitely have a point here - so I opt for the implicit , Cheers, Rainer But, if not equal to 25, what would be expected? An error, ...? 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] About commit named Allow multi-line properties to be specified in property blocks
Unless I have missed something in the e-mails, the new syntax is to concatenate new variables to the var property. Not modifying the values currently stored in some variable. That is, #+property: var foo=2 #+property: var+ 5 (not specifying the variable name ) should not be allowed and #+property: var foo=2 #+property: var+ foo=5 #+property: var+ bar=bar should result in foo=5 and bar=bar. Is modifying a variable also a new feature? -- Darlan At Tue, 8 Nov 2011 11:06:48 +0100, Rainer M Krug r.m.k...@gmail.com wrote: [1 text/plain; ISO-8859-1 (7bit)] On Tue, Nov 8, 2011 at 10:58 AM, Sebastien Vauban wxhgmqzgw...@spammotel.com wrote: Hi Rainer, Rainer M Krug wrote: * appending to a file-wide property :PROPERTIES: :var+: , baz=3 :END: To be honest, the only thing that I dislike is the comma in the above line. Not intuitive at all. Quite hard to read. Can't the comma be implicitly added by the `+' after the property name? On the one hand, it might have one additional advantage: #+property: var foo=This is a very long text #+property: var+ with even more. I don't think such a construction would be tolerated. I guess you must write a var name (foo, bar, baz, ...) after the `var+' keyword. Would foo be: This is a very long text with even more To be accurate, it would have become: This is a very long textwith even more if such a concatenation would be implied. Correct - missing space. Could one make the , implicit, if the value follows the x=y style, while otherwise just concatenate the value to the one before? I guess this is going too far, as Babel is untyped: what about... #+property: var foo=2 #+property: var+ 5 Does foo become equal to 25? (I know I exaggerate somehow, but just to show I guess such extensions are simply not possible without explicit types). You definitely have a point here - so I opt for the implicit , Cheers, Rainer But, if not equal to 25, what would be expected? An error, ...? 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 [2 text/html; ISO-8859-1 (quoted-printable)]
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
How do you unset a var? By resetting the list with a new var (without `+'), See, the example in my original email, a property with var (no +) wipes out any previously existing var properties. and adding all the other valid vars? If so, not really unsetting... You simply void all vars, and create new definitions... yes Exactly - with unseting var, I don't refer to unsetting a single variable, but all variables. But as we have the var+, what about a var- to unset a single variable? This is not possible. Up until this point we continue to treat the var property as any other property, and we just allow the construction of a long var value, such as foo=1, bar=2, baz=3. Introducing a var- would be a large departure from current property handling and would require parsing lines like the above. Best -- Eric Best regards, Seb -- Sebastien Vauban -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
Could one make the , implicit, if the value follows the x=y style, while otherwise just concatenate the value to the one before? I guess this is going too far, as Babel is untyped: what about... #+property: var foo=2 #+property: var+ 5 Does foo become equal to 25? yes #+PROPERTY: var foo=2 #+PROPERTY: var+ 5 #+begin_src emacs-lisp foo #+end_src #+results: : 25 (I know I exaggerate somehow, but just to show I guess such extensions are simply not possible without explicit types). I think by types you mean something more like syntactic parsing? Babel does have three types, strings, numbers, and lists. You definitely have a point here - so I opt for the implicit , Keep in mind that the above applies to *all* Org-mode properties, not just variables, which is why I did not want to force an assumed comma separator. For example, #+PROPERTY: Disks 1 2 3 4 5 6 7 #+PROPERTY: Disks+ 8 9 10 11 12 13 #+begin_src emacs-lisp org-file-properties #+end_src #+results: | (var . foo=25) | (Disks . 1 2 3 4 5 6 78 9 10 11 12 13) | Although in this case the 78 is certainly unexpected. Perhaps inserting an assumed space separator would be more intuitive? If we were to go that way it may be possible to allow variable specifications such as #+PROPERTY: var foo=1 bar=2 in which case properties could be easily specified on multiple lines using a default space separator. If this seems like a good way to go I can try to update my previous patch. Thanks -- Eric Cheers, Rainer But, if not equal to 25, what would be expected? An error, ...? Best regards, Seb -- Sebastien Vauban -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
Hi Darlan, Darlan Cavalcante Moreira wrote: Unless I have missed something in the e-mails, the new syntax is to concatenate new variables to the var property. Not modifying the values currently stored in some variable. That is, #+property: var foo=2 #+property: var+ 5 (not specifying the variable name ) should not be allowed By showing this example, I wanted to show that this proposition (of Rainer) seemed wrong to me. This is much too complex, and I think there is no use case to support such a thing. and #+property: var foo=2 #+property: var+ foo=5 #+property: var+ bar=bar should result in foo=5 and bar=bar. Yep -- iff the comma is implied (implicitly), what's not currently the case. Is modifying a variable also a new feature? Not (to me). Best regards, Seb -- Sebastien Vauban
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
Perhaps inserting an assumed space separator would be more intuitive? If we were to go that way it may be possible to allow variable specifications such as #+PROPERTY: var foo=1 bar=2 in which case properties could be easily specified on multiple lines using a default space separator. If this seems like a good way to go I can try to update my previous patch. I've updated the patch, the newest version is attached. It results in the following behavior. #+property: var foo=1 #+property: var+ bar=2 #+begin_src emacs-lisp (+ foo bar) #+end_src #+results: : 3 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=1 bar=2 * overwriting a file-wide property :PROPERTIES: :var: foo=7 :END: #+begin_src emacs-lisp foo #+end_src #+results: : 7 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=7 * appending to a file-wide property :PROPERTIES: :var+: baz=3 :END: #+begin_src emacs-lisp (+ foo bar baz) #+end_src #+results: : 6 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=1 bar=2 baz=3 From 2a4bc429a38470b71baabf73d160359f8f87c9de Mon Sep 17 00:00:00 2001 From: Eric Schulte schulte.e...@gmail.com Date: Mon, 7 Nov 2011 14:49:42 -0700 Subject: [PATCH] property names ending in plus accumulate This results in the following behavior. #+property: var foo=1 #+property: var+ bar=2 #+begin_src emacs-lisp (+ foo bar) #+end_src #+results: : 3 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=1 bar=2 * overwriting a file-wide property :PROPERTIES: :var: foo=7 :END: #+begin_src emacs-lisp foo #+end_src #+results: : 7 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=7 * appending to a file-wide property :PROPERTIES: :var+: baz=3 :END: #+begin_src emacs-lisp (+ foo bar baz) #+end_src #+results: : 6 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=1 bar=2 baz=3 * lisp/org.el (org-update-property-plist): Updates a given property list with a property name and a property value. (org-set-regexps-and-options): Use org-update-property-plist. (org-entry-get): Use org-update-property-plist. * testing/examples/property-inheritance.org: Example file for testing appending property behavior. * testing/lisp/test-property-inheritance.el: Tests of appending property behavior. * lisp/ob.el (org-babel-balanced-split): Allow splitting on single characters as well as groups of two characters. (org-babel-parse-multiple-vars): Split variables on single spaces. --- lisp/ob.el| 13 -- lisp/org.el | 47 +++--- testing/examples/property-inheritance.org | 36 + testing/lisp/test-property-inheritance.el | 61 + 4 files changed, 138 insertions(+), 19 deletions(-) create mode 100644 testing/examples/property-inheritance.org create mode 100644 testing/lisp/test-property-inheritance.el diff --git a/lisp/ob.el b/lisp/ob.el index d94b4b6..a1526bc 100644 --- a/lisp/ob.el +++ b/lisp/ob.el @@ -1118,8 +1118,10 @@ instances of \[ \t]:\ set ALTS to '((32 9) . 58). (flet ((matches (ch spec) (or (and (numberp spec) (= spec ch)) (member ch spec))) (matched (ch last) - (and (matches ch (cdr alts)) - (matches last (car alts) + (if (consp alts) + (and (matches ch (cdr alts)) + (matches last (car alts))) + (matches ch alts (let ((balance 0) (partial nil) (lst nil) (last 0)) (mapc (lambda (ch) ; split on [] or () balanced instances of [ \t]: (setq balance (+ balance @@ -1128,7 +1130,10 @@ instances of \[ \t]:\ set ALTS to '((32 9) . 58). (t 0 (setq partial (cons ch partial)) (when (and (= balance 0) (matched ch last)) - (setq lst (cons (apply #'string (nreverse (cddr partial))) + (setq lst (cons (apply #'string (nreverse + (if (consp alts) + (cddr partial) + (cdr partial lst)) (setq partial nil)) (setq last ch)) @@ -1163,7 +1168,7 @@ shown below. (mapc (lambda (pair) (if (eq (car pair) :var) (mapcar (lambda (v) (push (cons :var (org-babel-trim v)) results)) - (org-babel-balanced-split (cdr pair) '(44 . (32 9 + (org-babel-balanced-split (cdr pair) 32)) (push pair results))) header-arguments) (nreverse results))) diff --git a/lisp/org.el b/lisp/org.el index 5c4ea33..d74e994 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -4438,6 +4438,15 @@ in the #+STARTUP line, the corresponding variable, and the value to set this variable to if the option is found. An optional forth element PUSH means to push this value onto the list in the variable.) +(defun org-update-property-plist (key val
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
The attached patch implements this latest propname+ suggestion. When applied it results in the behavior shown below. I'm inclined to go with this as a solution moving forward. Thoughts? #+property: varfoo=1 #+property: var+ , bar=2 #+begin_src emacs-lisp (+ foo bar) #+end_src #+results: : 3 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=1, bar=2 * overwriting a file-wide property :PROPERTIES: :var: foo=7 :END: #+begin_src emacs-lisp foo #+end_src #+results: : 7 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=7 * appending to a file-wide property :PROPERTIES: :var+: , baz=3 :END: #+begin_src emacs-lisp (+ foo bar baz) #+end_src #+results: : 6 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=1, bar=2, baz=3 From 1bb2009c419e5ae6c912e863b13cb02a1f1ea720 Mon Sep 17 00:00:00 2001 From: Eric Schulte schulte.e...@gmail.com Date: Mon, 7 Nov 2011 14:49:42 -0700 Subject: [PATCH] property names ending in plus accumulate This results in the following behavior. #+property: varfoo=1 #+property: var+ , bar=2 #+begin_src emacs-lisp (+ foo bar) #+end_src #+results: : 3 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=1, bar=2 * overwriting a file-wide property :PROPERTIES: :var: foo=7 :END: #+begin_src emacs-lisp foo #+end_src #+results: : 7 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=7 * appending to a file-wide property :PROPERTIES: :var+: , baz=3 :END: #+begin_src emacs-lisp (+ foo bar baz) #+end_src #+results: : 6 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=1, bar=2, baz=3 * lisp/org.el (org-update-property-plist): Updates a given property list with a property name and a property value. (org-set-regexps-and-options): Use org-update-property-plist. (org-entry-get): Use org-update-property-plist. * testing/examples/property-inheritance.org: Example file for testing appending property behavior. * testing/lisp/test-property-inheritance.el: Tests of appending property behavior. properties with names ending in + accumulate rather than overwrite This results in the following behavior. #+property: varfoo=1 #+property: var+ , bar=2 #+begin_src emacs-lisp (+ foo bar) #+end_src #+results: : 3 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=1, bar=2 * overwriting a file-wide property :PROPERTIES: :var: foo=7 :END: #+begin_src emacs-lisp foo #+end_src #+results: : 7 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=7 * appending to a file-wide property :PROPERTIES: :var+: , baz=3 :END: #+begin_src emacs-lisp (+ foo bar baz) #+end_src #+results: : 6 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=1, bar=2, baz=3 * lisp/org.el (org-update-property-plist): Updates a given property list with a property name and a property value. (org-set-regexps-and-options): Use org-update-property-plist. (org-entry-get): Use org-update-property-plist. * testing/examples/property-inheritance.org: Example file for testing appending property behavior. * testing/lisp/test-property-inheritance.el: Tests of appending property behavior. properties with names ending in + accumulate rather than overwrite This results in the following behavior. #+property: varfoo=1 #+property: var+ , bar=2 #+begin_src emacs-lisp (+ foo bar) #+end_src #+results: : 3 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=1, bar=2 * overwriting a file-wide property :PROPERTIES: :var: foo=7 :END: #+begin_src emacs-lisp foo #+end_src #+results: : 7 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=7 * appending to a file-wide property :PROPERTIES: :var+: , baz=3 :END: #+begin_src emacs-lisp (+ foo bar baz) #+end_src #+results: : 6 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=1, bar=2, baz=3 * lisp/org.el (org-update-property-plist): Updates a given property list with a property name and a property value. (org-set-regexps-and-options): Use org-update-property-plist. (org-entry-get): Use org-update-property-plist. * testing/examples/property-inheritance.org: Example file for testing appending property behavior. * testing/lisp/test-property-inheritance.el: Tests of appending property behavior. --- lisp/org.el | 47 +++--- testing/examples/property-inheritance.org | 36
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
On Thu, Nov 3, 2011 at 9:23 PM, Eric Schulte schulte.e...@gmail.com wrote: One more idea that has occurred to me, it should give all of the functionality which we desire (i.e., the ability for a property value to span multiple lines and to be accumulated at the subtree level), and it should require *no* new syntax. The only problem is it puts a limitation on possible property names -- namely that they can not end with the + character. The proposal is, when a property name ends in +, the value is appended to the corresponding property, rather than replacing it, so #+PROPERTY: var foo=1 #+PROPERTY: var bar=2 results in '((var . bar=2)) #+PROPERTY: varfoo=1 #+PROPERTY: var+ , bar=2 results in '((var . foo=1, bar=2)) This way subtree properties could be used as well, e.g., #+PROPERTY: var foo=1 * subtree :PROPERTIES: :var+: bar=2 :CUSTOM_ID: something :END: Just another thought. I like that suggestion - it is clear, easy to understand, gives other advantages (you can unset variables in a subtree - which would be an added bonus) and does not require any large changes in org files. This suggestion would get my vote. Cheers, Rainer Best -- Eric Eric Schulte schulte.e...@gmail.com writes: I don't understand why the `org-accumulated-properties-alist' solution seems like a hack, could someone elaborate. To me that still feels like the most natural solution. more below... 2) Cumulative properties? Here is a suggestion: use a syntaxe like #+var: foo 1 There is also #+bind:, whose purpose is close enough. Indeed. Eric, would it be possible to use #+bind foo 1 instead of #+property var foo=1 No, this would not for subtree-level properties, i.e., in a property block under a subtree there would be no way to tell if a property is a #+var:. I think if this were an approach, a more elegant solution would be for users to customize the `org-babel-default-header-args' variable using Emacs' file-local-variable feature -- which is possible now and may end up being the best solution. 3) Wrapping/folding long #+xxx lines? This is an independant request -- see Robert McIntyre's recent question on the list. The problem is that fill-paragraph on long #+xxx lines breaks the line into comment lines, which is wrong. Filling like this: #+TBLFM: @3$1=@1$1+@2$1::@3$2=@1$2+@2$2::...::... : @3$2=@1$2+@2$2::... : @3$2=@1$2+@2$2::... #+tblfm: ... #+tblfm: ... #+tblfm: ... Not very elegant, but perhaps more efficient/consistent. I like this solution, especially as I have often struggled with long and unreadable tblfm lines. The problem with using this for property lines would be in the case of #+property: foo bar #+property: baz qux whether the above should be parsed as '((foo . bar) (baz . qux)) or '((foo . bar baz qux)) But maybe generalizing the #+begin_xxx syntax for *all* #+xxx keywords. This would make the current org-internals-oriented/content-oriented difference between #+xxx and #+begin_xxx obsolete I suggest to avoid such a thing. Here are a few, more or less valid, reasons: - That distinction is useful for the user (clear separation between contents and Org control). - It would penalize usage of special blocks. - The need is localized to very few keywords: it isn't worth the added complexity. - It would be ugly: no more nice stacking of keywords, but a mix of blocks and keywords, and blocks on top of blocks... Org syntax may not be the prettiest ever, it doesn't deserve that. - It would be a real pain to parse. Well, I agree with most of the reasons. Glad you stated them clearly. Yes, I agree some of the above are very motivating. but this would spare us the cost of new syntax. On the contrary, creating a block for each keyword would mean a lot of new syntax. We currently have 8 types of blocks (not counting dynamic blocks, whose syntax is a bit different), all requiring to be parsed differently: 1. Center blocks, 2. Comment blocks, 3. Example blocks, 4. Export blocks, 5. Quote blocks, 6. Special blocks, 7. Src blocks, 8. Verse blocks. I'm not sure what do you mean by requiring to be parsed differently. Can you explain it? I understand they should be treated differently by the exporters, but I don't understand why they would need to be parsed differently. I also wouldn't think of this as new syntax, I don't see 8 rules for the 8 types above but rather one rule along the lines of #+begin_SOMETHING where the SOMETHING can be anything. Best -- Eric My idea was to avoid parsing both #+html and #+begin_html. And that #+begin_xxx syntax is already available for folding, which is a feature we might want for #+text and
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
I liked this suggestion. In a sense, it is similar to the inherit keyword I had suggested before, but now the keyword (the plus sign) is part of the variable name. But the reason I really liked it is because it is clear to understand. One can compare it to the += operator some languages have. That is, we can understand `:var: bar=2` as var=bar=2 and `:var+: bar=2` as var+=bar=2.` -- Darlan At Fri, 4 Nov 2011 09:02:43 +0100, Rainer M Krug r.m.k...@gmail.com wrote: On Thu, Nov 3, 2011 at 9:23 PM, Eric Schulte schulte.e...@gmail.com wrote: One more idea that has occurred to me, it should give all of the functionality which we desire (i.e., the ability for a property value to span multiple lines and to be accumulated at the subtree level), and it should require *no* new syntax. The only problem is it puts a limitation on possible property names -- namely that they can not end with the + character. The proposal is, when a property name ends in +, the value is appended to the corresponding property, rather than replacing it, so #+PROPERTY: var foo=1 #+PROPERTY: var bar=2 results in '((var . bar=2)) #+PROPERTY: varfoo=1 #+PROPERTY: var+ , bar=2 results in '((var . foo=1, bar=2)) This way subtree properties could be used as well, e.g., #+PROPERTY: var foo=1 * subtree :PROPERTIES: :var+: bar=2 :CUSTOM_ID: something :END: Just another thought. I like that suggestion - it is clear, easy to understand, gives other advantages (you can unset variables in a subtree - which would be an added bonus) and does not require any large changes in org files. This suggestion would get my vote. Cheers, Rainer Best -- Eric Eric Schulte schulte.e...@gmail.com writes: I don't understand why the `org-accumulated-properties-alist' solution seems like a hack, could someone elaborate. To me that still feels like the most natural solution. more below... 2) Cumulative properties? Here is a suggestion: use a syntaxe like #+var: foo 1 There is also #+bind:, whose purpose is close enough. Indeed. Eric, would it be possible to use #+bind foo 1 instead of #+property var foo=1 No, this would not for subtree-level properties, i.e., in a property block under a subtree there would be no way to tell if a property is a #+var:. I think if this were an approach, a more elegant solution would be for users to customize the `org-babel-default-header-args' variable using Emacs' file-local-variable feature -- which is possible now and may end up being the best solution. 3) Wrapping/folding long #+xxx lines? This is an independant request -- see Robert McIntyre's recent question on the list. The problem is that fill-paragraph on long #+xxx lines breaks the line into comment lines, which is wrong. Filling like this: #+TBLFM: @3$1=@1$1+@2$1::@3$2=@1$2+@2$2::...::... : @3$2=@1$2+@2$2::... : @3$2=@1$2+@2$2::... #+tblfm: ... #+tblfm: ... #+tblfm: ... Not very elegant, but perhaps more efficient/consistent. I like this solution, especially as I have often struggled with long and unreadable tblfm lines. The problem with using this for property lines would be in the case of #+property: foo bar #+property: baz qux whether the above should be parsed as '((foo . bar) (baz . qux)) or '((foo . bar baz qux)) But maybe generalizing the #+begin_xxx syntax for *all* #+xxx keywords. This would make the current org-internals-oriented/content-oriented difference between #+xxx and #+begin_xxx obsolete I suggest to avoid such a thing. Here are a few, more or less valid, reasons: - That distinction is useful for the user (clear separation between contents and Org control). - It would penalize usage of special blocks. - The need is localized to very few keywords: it isn't worth the added complexity. - It would be ugly: no more nice stacking of keywords, but a mix of blocks and keywords, and blocks on top of blocks... Org syntax may not be the prettiest ever, it doesn't deserve that. - It would be a real pain to parse. Well, I agree with most of the reasons. Glad you stated them clearly. Yes, I agree some of the above are very motivating. but this would spare us the cost of new syntax. On the contrary, creating a block for each keyword would mean a lot of new syntax. We currently have 8 types of blocks (not counting dynamic blocks, whose syntax is a bit different), all requiring to be parsed differently: 1. Center blocks, 2. Comment blocks, 3. Example blocks, 4. Export blocks, 5. Quote blocks, 6. Special blocks, 7. Src blocks, 8. Verse
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
Darlan Cavalcante Moreira darc...@gmail.com writes: I liked this suggestion. In a sense, it is similar to the inherit keyword I had suggested before, but now the keyword (the plus sign) is part of the variable name. Oh yes, I didn't realize that when I first posted this suggestion but it is very similar to your suggested inherit keyword, But the reason I really liked it is because it is clear to understand. One can compare it to the += operator some languages have. That is, we can understand `:var: bar=2` as var=bar=2 and `:var+: bar=2` as var+=bar=2.` Agreed, it was the limitation of possible values which I didn't like about your inherit suggestion, but this approach switches the limitation to the property name rather than the property value which is somehow more appealing. Cheers -- Eric -- Darlan At Fri, 4 Nov 2011 09:02:43 +0100, Rainer M Krug r.m.k...@gmail.com wrote: On Thu, Nov 3, 2011 at 9:23 PM, Eric Schulte schulte.e...@gmail.com wrote: One more idea that has occurred to me, it should give all of the functionality which we desire (i.e., the ability for a property value to span multiple lines and to be accumulated at the subtree level), and it should require *no* new syntax. The only problem is it puts a limitation on possible property names -- namely that they can not end with the + character. The proposal is, when a property name ends in +, the value is appended to the corresponding property, rather than replacing it, so #+PROPERTY: var foo=1 #+PROPERTY: var bar=2 results in '((var . bar=2)) #+PROPERTY: varfoo=1 #+PROPERTY: var+ , bar=2 results in '((var . foo=1, bar=2)) This way subtree properties could be used as well, e.g., #+PROPERTY: var foo=1 * subtree :PROPERTIES: :var+: bar=2 :CUSTOM_ID: something :END: Just another thought. I like that suggestion - it is clear, easy to understand, gives other advantages (you can unset variables in a subtree - which would be an added bonus) and does not require any large changes in org files. This suggestion would get my vote. Cheers, Rainer Best -- Eric Eric Schulte schulte.e...@gmail.com writes: I don't understand why the `org-accumulated-properties-alist' solution seems like a hack, could someone elaborate. To me that still feels like the most natural solution. more below... 2) Cumulative properties? Here is a suggestion: use a syntaxe like #+var: foo 1 There is also #+bind:, whose purpose is close enough. Indeed. Eric, would it be possible to use #+bind foo 1 instead of #+property var foo=1 No, this would not for subtree-level properties, i.e., in a property block under a subtree there would be no way to tell if a property is a #+var:. I think if this were an approach, a more elegant solution would be for users to customize the `org-babel-default-header-args' variable using Emacs' file-local-variable feature -- which is possible now and may end up being the best solution. 3) Wrapping/folding long #+xxx lines? This is an independant request -- see Robert McIntyre's recent question on the list. The problem is that fill-paragraph on long #+xxx lines breaks the line into comment lines, which is wrong. Filling like this: #+TBLFM: @3$1=@1$1+@2$1::@3$2=@1$2+@2$2::...::... : @3$2=@1$2+@2$2::... : @3$2=@1$2+@2$2::... #+tblfm: ... #+tblfm: ... #+tblfm: ... Not very elegant, but perhaps more efficient/consistent. I like this solution, especially as I have often struggled with long and unreadable tblfm lines. The problem with using this for property lines would be in the case of #+property: foo bar #+property: baz qux whether the above should be parsed as '((foo . bar) (baz . qux)) or '((foo . bar baz qux)) But maybe generalizing the #+begin_xxx syntax for *all* #+xxx keywords. This would make the current org-internals-oriented/content-oriented difference between #+xxx and #+begin_xxx obsolete I suggest to avoid such a thing. Here are a few, more or less valid, reasons: - That distinction is useful for the user (clear separation between contents and Org control). - It would penalize usage of special blocks. - The need is localized to very few keywords: it isn't worth the added complexity. - It would be ugly: no more nice stacking of keywords, but a mix of blocks and keywords, and blocks on top of blocks... Org syntax may not be the prettiest ever, it doesn't deserve that. - It would be a real pain to parse. Well, I agree with most of the reasons. Glad you stated them clearly. Yes, I agree some of the above are very motivating. but this would spare us the cost
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
On 11/3/11 2:26 AM, Bastien wrote: Hi Nicolas, Nicolas Goazioun.goaz...@gmail.com writes: (...) There is also #+bind:, whose purpose is close enough. Indeed. Eric, would it be possible to use #+bind foo 1 instead of #+property var foo=1 Correct me if I'm wrong, but the purpose of #+BIND is to specify a file local variable, isn't it? The manual gives one example of how to modify export settings with it. With Babel blocks, there should be clarity what variables are to be passed to the block as arguments, and what variables should not. Currently this is completely clear: Only variables named in a `var' property or header argument are passed. Using =#+bind foo 1= would be ambiguous; you wouldn't know when it's for Babel and when it's not. Say we make Babel use BIND values, and someone has this setup: #+BIND: org-export-latex-low-levels itemize #+BIND: foo 1 #+BIND: bar 2 Then this: #+BEGIN_SRC emacs-lisp (+ foo bar) #+END_SRC would tangle to something like: (let ((org-export-latex-low-levels (guote itemize)) (foo (quote 1)) (bar (quote 2))) (+ foo bar)) -- which was not the intention. Yours, Christian
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
On 11/3/11 2:42 AM, Bastien wrote: But allowing a top-level :PROPERTIES: drawer with properties whose scope is the entire file looks like a good idea to me. How other would feel about this? Not sure if this is already clear, but just in case: The functionality is already there. PROPERTY lines set buffer-wide properties. This works now: #+TITLE: My foobar file #+PROPERTY: foo 1 #+PROPERTY: bar 2 #+PROPERTY: baz 3 Replacing it with a top-level property drawer before the outline would make another bit of syntax redundant, and it would sometimes save a bit of typing (if there are many buffer-wide properties tobe set): #+TITLE: My foobar file :PROPERTIES: :foo: 1 :bar: 2 :baz: 3 :END: I have come to expect that any file-wide settings are in #+... lines and that any property drawers are associated with outline entries. I don't know how important it is to maintain those expectations. Yours, Christian
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
Christian Moe m...@christianmoe.com wrote: On 11/3/11 2:26 AM, Bastien wrote: Hi Nicolas, Nicolas Goazioun.goaz...@gmail.com writes: (...) There is also #+bind:, whose purpose is close enough. Indeed. Eric, would it be possible to use #+bind foo 1 instead of #+property var foo=1 Correct me if I'm wrong, but the purpose of #+BIND is to specify a file local variable, isn't it? The manual gives one example of how to modify export settings with it. It's actually more restricted than that: during preprocessing, the function org-install-letbind adds the bindings as file-locals *during export*. With Babel blocks, there should be clarity what variables are to be passed to the block as arguments, and what variables should not. Currently this is completely clear: Only variables named in a `var' property or header argument are passed. Using =#+bind foo 1= would be ambiguous; you wouldn't know when it's for Babel and when it's not. Say we make Babel use BIND values, and someone has this setup: #+BIND: org-export-latex-low-levels itemize #+BIND: foo 1 #+BIND: bar 2 Then this: #+BEGIN_SRC emacs-lisp (+ foo bar) #+END_SRC would tangle to something like: (let ((org-export-latex-low-levels (guote itemize)) (foo (quote 1)) (bar (quote 2))) (+ foo bar)) -- which was not the intention. I agree - the bind namespace and the code block variable name space should be separate. BIND was iirc Carsten's throwing up his hands when people were asking for more and more options to be settable from within the file: he built a general (if not particularly convenient) mechanism to allow people to do just that. Nick Yours, Christian
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
I don't understand why the `org-accumulated-properties-alist' solution seems like a hack, could someone elaborate. To me that still feels like the most natural solution. more below... 2) Cumulative properties? Here is a suggestion: use a syntaxe like #+var: foo 1 There is also #+bind:, whose purpose is close enough. Indeed. Eric, would it be possible to use #+bind foo 1 instead of #+property var foo=1 No, this would not for subtree-level properties, i.e., in a property block under a subtree there would be no way to tell if a property is a #+var:. I think if this were an approach, a more elegant solution would be for users to customize the `org-babel-default-header-args' variable using Emacs' file-local-variable feature -- which is possible now and may end up being the best solution. 3) Wrapping/folding long #+xxx lines? This is an independant request -- see Robert McIntyre's recent question on the list. The problem is that fill-paragraph on long #+xxx lines breaks the line into comment lines, which is wrong. Filling like this: #+TBLFM: @3$1=@1$1+@2$1::@3$2=@1$2+@2$2::...::... : @3$2=@1$2+@2$2::... : @3$2=@1$2+@2$2::... #+tblfm: ... #+tblfm: ... #+tblfm: ... Not very elegant, but perhaps more efficient/consistent. I like this solution, especially as I have often struggled with long and unreadable tblfm lines. The problem with using this for property lines would be in the case of #+property: foo bar #+property: baz qux whether the above should be parsed as '((foo . bar) (baz . qux)) or '((foo . bar baz qux)) But maybe generalizing the #+begin_xxx syntax for *all* #+xxx keywords. This would make the current org-internals-oriented/content-oriented difference between #+xxx and #+begin_xxx obsolete I suggest to avoid such a thing. Here are a few, more or less valid, reasons: - That distinction is useful for the user (clear separation between contents and Org control). - It would penalize usage of special blocks. - The need is localized to very few keywords: it isn't worth the added complexity. - It would be ugly: no more nice stacking of keywords, but a mix of blocks and keywords, and blocks on top of blocks... Org syntax may not be the prettiest ever, it doesn't deserve that. - It would be a real pain to parse. Well, I agree with most of the reasons. Glad you stated them clearly. Yes, I agree some of the above are very motivating. but this would spare us the cost of new syntax. On the contrary, creating a block for each keyword would mean a lot of new syntax. We currently have 8 types of blocks (not counting dynamic blocks, whose syntax is a bit different), all requiring to be parsed differently: 1. Center blocks, 2. Comment blocks, 3. Example blocks, 4. Export blocks, 5. Quote blocks, 6. Special blocks, 7. Src blocks, 8. Verse blocks. I'm not sure what do you mean by requiring to be parsed differently. Can you explain it? I understand they should be treated differently by the exporters, but I don't understand why they would need to be parsed differently. I also wouldn't think of this as new syntax, I don't see 8 rules for the 8 types above but rather one rule along the lines of #+begin_SOMETHING where the SOMETHING can be anything. Best -- Eric My idea was to avoid parsing both #+html and #+begin_html. And that #+begin_xxx syntax is already available for folding, which is a feature we might want for #+text and keywords like that. I would suggest this rule: #+begin_ is always for _content_ while #+keyword is always for internals that are removed when exporting. #+text, #+html, #+LaTeX are a few exception I can think of. Best, -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
But allowing a top-level :PROPERTIES: drawer with properties whose scope is the entire file looks like a good idea to me. I don't see what this would add, how would this solve the need for multi-line properties, and how would it differ from IMO being uglier than a series of #+PROPERTY: lines. Best -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
While I still think `org-accumulated-properties-alist' is the most powerful solution -- as it is the only solution which allows a subtree property block to extend rather than overwrite a file-wide property. I've been thinking a little bit more about these issues and I'm returning to a previous suggestion... Do we still think that using #+KEYWORD+: lines is an ugly way to specify multi-line values for keywords. I think this has the advantages of simplicity, intuitiveness (its use is obvious once you see it), and generality (i.e., this could be used to allow multi-line tblfm lines). Just another thought -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
Eric Schulte schulte.e...@gmail.com writes: On the contrary, creating a block for each keyword would mean a lot of new syntax. We currently have 8 types of blocks (not counting dynamic blocks, whose syntax is a bit different), all requiring to be parsed differently: 1. Center blocks, 2. Comment blocks, 3. Example blocks, 4. Export blocks, 5. Quote blocks, 6. Special blocks, 7. Src blocks, 8. Verse blocks. I'm not sure what do you mean by requiring to be parsed differently. Can you explain it? I understand they should be treated differently by the exporters, but I don't understand why they would need to be parsed differently. I also wouldn't think of this as new syntax, I don't see 8 rules for the 8 types above but rather one rule along the lines of #+begin_SOMETHING where the SOMETHING can be anything. Well, certainly, from a Press TAB on #+begin_ line, they have exactly the same meaning, and could as well be labelled #+begin_SOMETHING. But, - If I consider fontification, Src blocks differ from Example blocks, which differ from everything else. - If I consider `org-edit-special', C-c ' will bring you to a buffer with a special mode in Src blocks, fundamental mode in Example blocks and Verse blocks. - If I consider lists, you can have them in Quote blocks, but not in Export blocks or Verse blocks, for example. - If I consider indentation, it will be ignored for Example blocks (and should do the same for Verse blocks), could do something entirely different on Src blocks, and will indent normally, i.e. Quote blocks. - If I consider recursion, you can have Quote blocks inside Center blocks, but not inside Export blocks. - If I consider options on the begin_ line, Example blocks accept them, but not Center blocks. - If I consider entities, you can have them in Verse blocks but not in Example blocks - If I consider export, obviously, they will all be treated very differently. And I'm pretty sure I'm forgetting some other case. So, yes, from the moon, they're pretty much indistinguishable ;) From an Org point of view, they have 8 different meanings and, as such, need to be parsed differently. At least, I've had to proceed that way when I wrote an Org parser. Regards, -- Nicolas Goaziou
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
One more idea that has occurred to me, it should give all of the functionality which we desire (i.e., the ability for a property value to span multiple lines and to be accumulated at the subtree level), and it should require *no* new syntax. The only problem is it puts a limitation on possible property names -- namely that they can not end with the + character. The proposal is, when a property name ends in +, the value is appended to the corresponding property, rather than replacing it, so #+PROPERTY: var foo=1 #+PROPERTY: var bar=2 results in '((var . bar=2)) #+PROPERTY: varfoo=1 #+PROPERTY: var+ , bar=2 results in '((var . foo=1, bar=2)) This way subtree properties could be used as well, e.g., #+PROPERTY: var foo=1 * subtree :PROPERTIES: :var+: bar=2 :CUSTOM_ID: something :END: Just another thought. Best -- Eric Eric Schulte schulte.e...@gmail.com writes: I don't understand why the `org-accumulated-properties-alist' solution seems like a hack, could someone elaborate. To me that still feels like the most natural solution. more below... 2) Cumulative properties? Here is a suggestion: use a syntaxe like #+var: foo 1 There is also #+bind:, whose purpose is close enough. Indeed. Eric, would it be possible to use #+bind foo 1 instead of #+property var foo=1 No, this would not for subtree-level properties, i.e., in a property block under a subtree there would be no way to tell if a property is a #+var:. I think if this were an approach, a more elegant solution would be for users to customize the `org-babel-default-header-args' variable using Emacs' file-local-variable feature -- which is possible now and may end up being the best solution. 3) Wrapping/folding long #+xxx lines? This is an independant request -- see Robert McIntyre's recent question on the list. The problem is that fill-paragraph on long #+xxx lines breaks the line into comment lines, which is wrong. Filling like this: #+TBLFM: @3$1=@1$1+@2$1::@3$2=@1$2+@2$2::...::... : @3$2=@1$2+@2$2::... : @3$2=@1$2+@2$2::... #+tblfm: ... #+tblfm: ... #+tblfm: ... Not very elegant, but perhaps more efficient/consistent. I like this solution, especially as I have often struggled with long and unreadable tblfm lines. The problem with using this for property lines would be in the case of #+property: foo bar #+property: baz qux whether the above should be parsed as '((foo . bar) (baz . qux)) or '((foo . bar baz qux)) But maybe generalizing the #+begin_xxx syntax for *all* #+xxx keywords. This would make the current org-internals-oriented/content-oriented difference between #+xxx and #+begin_xxx obsolete I suggest to avoid such a thing. Here are a few, more or less valid, reasons: - That distinction is useful for the user (clear separation between contents and Org control). - It would penalize usage of special blocks. - The need is localized to very few keywords: it isn't worth the added complexity. - It would be ugly: no more nice stacking of keywords, but a mix of blocks and keywords, and blocks on top of blocks... Org syntax may not be the prettiest ever, it doesn't deserve that. - It would be a real pain to parse. Well, I agree with most of the reasons. Glad you stated them clearly. Yes, I agree some of the above are very motivating. but this would spare us the cost of new syntax. On the contrary, creating a block for each keyword would mean a lot of new syntax. We currently have 8 types of blocks (not counting dynamic blocks, whose syntax is a bit different), all requiring to be parsed differently: 1. Center blocks, 2. Comment blocks, 3. Example blocks, 4. Export blocks, 5. Quote blocks, 6. Special blocks, 7. Src blocks, 8. Verse blocks. I'm not sure what do you mean by requiring to be parsed differently. Can you explain it? I understand they should be treated differently by the exporters, but I don't understand why they would need to be parsed differently. I also wouldn't think of this as new syntax, I don't see 8 rules for the 8 types above but rather one rule along the lines of #+begin_SOMETHING where the SOMETHING can be anything. Best -- Eric My idea was to avoid parsing both #+html and #+begin_html. And that #+begin_xxx syntax is already available for folding, which is a feature we might want for #+text and keywords like that. I would suggest this rule: #+begin_ is always for _content_ while #+keyword is always for internals that are removed when exporting. #+text, #+html, #+LaTeX are a few exception I can think of. Best, -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
Nicolas Goaziou n.goaz...@gmail.com writes: Eric Schulte schulte.e...@gmail.com writes: On the contrary, creating a block for each keyword would mean a lot of new syntax. We currently have 8 types of blocks (not counting dynamic blocks, whose syntax is a bit different), all requiring to be parsed differently: 1. Center blocks, 2. Comment blocks, 3. Example blocks, 4. Export blocks, 5. Quote blocks, 6. Special blocks, 7. Src blocks, 8. Verse blocks. I'm not sure what do you mean by requiring to be parsed differently. Can you explain it? I understand they should be treated differently by the exporters, but I don't understand why they would need to be parsed differently. I also wouldn't think of this as new syntax, I don't see 8 rules for the 8 types above but rather one rule along the lines of #+begin_SOMETHING where the SOMETHING can be anything. Well, certainly, from a Press TAB on #+begin_ line, they have exactly the same meaning, and could as well be labelled #+begin_SOMETHING. But, - If I consider fontification, Src blocks differ from Example blocks, which differ from everything else. - If I consider `org-edit-special', C-c ' will bring you to a buffer with a special mode in Src blocks, fundamental mode in Example blocks and Verse blocks. - If I consider lists, you can have them in Quote blocks, but not in Export blocks or Verse blocks, for example. - If I consider indentation, it will be ignored for Example blocks (and should do the same for Verse blocks), could do something entirely different on Src blocks, and will indent normally, i.e. Quote blocks. - If I consider recursion, you can have Quote blocks inside Center blocks, but not inside Export blocks. - If I consider options on the begin_ line, Example blocks accept them, but not Center blocks. - If I consider entities, you can have them in Verse blocks but not in Example blocks - If I consider export, obviously, they will all be treated very differently. And I'm pretty sure I'm forgetting some other case. So, yes, from the moon, they're pretty much indistinguishable ;) From an Org point of view, they have 8 different meanings and, as such, need to be parsed differently. At least, I've had to proceed that way when I wrote an Org parser. Point made :), I concede a huge difference between block types. I'm ultimately happy that the begin_property approach has not moved forward. Best -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
Dear all, here is my take on this issue. First of all, sorry that the #+begin_property caused confusion, I'm the one responsible as I suggested this suggestion to Eric. I can see three issues: 1) Consistent syntax for #+xxx and #+begin_xxx? Nicolas point is valid -- #+begin_xxx syntax is about content and formatting, not about Org's internal. #+xxx is mostly about Org's internals (#+author, #+date, #+property, etc) and sometimes about content, as a convenient way of inserting one-line content block (#+html, #+LaTeX, etc) #+begin_property does not fit well into this picture. 2) Cumulative properties? Org's manual describes #+property like this: `#+PROPERTY: Property_Name Value' This line sets a default inheritance value for entries in the current buffer, most useful for specifying the allowed values of a property. Note that #+property: var foo=1 does *not* fit into the syntax described above. It is more something like `#+PROPERTY: var Variable_Name=Value' Hence the problem of accumulating the values of var, which is not really a property name, but some syntactic clue to bind Variable_Name to its value. Here is a suggestion: use a syntaxe like #+var: foo 1 The difference between #+property and #+var would be that #+var is for setting general purpoes (elisp) variables, while #+property is for Org internals. Sorry if such a proposal has already been made and discussed. My feeling is that `org-accumulated-properties-alist' is complex and can be avoided -- but I need to think more about this. 3) Wrapping/folding long #+xxx lines? This is an independant request -- see Robert McIntyre's recent question on the list. The problem is that fill-paragraph on long #+xxx lines breaks the line into comment lines, which is wrong. Filling like this: #+TBLFM: @3$1=@1$1+@2$1::@3$2=@1$2+@2$2::...::... : @3$2=@1$2+@2$2::... : @3$2=@1$2+@2$2::... would feel more natural, at least to me. But maybe generalizing the #+begin_xxx syntax for *all* #+xxx keywords. This would make the current org-internals-oriented/content-oriented difference between #+xxx and #+begin_xxx obsolete, but this would spare us the cost of new syntax. Curious about input about this as well. Cheers, -- Bastien
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
Hello, Bastien b...@altern.org writes: 1) Consistent syntax for #+xxx and #+begin_xxx? Nicolas point is valid -- #+begin_xxx syntax is about content and formatting, not about Org's internal. #+xxx is mostly about Org's internals (#+author, #+date, #+property, etc) and sometimes about content, as a convenient way of inserting one-line content block (#+html, #+LaTeX, etc) For the sake of consistency, I would suggest to drop the export back-end relative keywords. #+html: and #+latex: are indeed disturbing exceptions to the rule. They are also not so convenient (a net gain of 2 lines). 2) Cumulative properties? Here is a suggestion: use a syntaxe like #+var: foo 1 There is also #+bind:, whose purpose is close enough. 3) Wrapping/folding long #+xxx lines? This is an independant request -- see Robert McIntyre's recent question on the list. The problem is that fill-paragraph on long #+xxx lines breaks the line into comment lines, which is wrong. Filling like this: #+TBLFM: @3$1=@1$1+@2$1::@3$2=@1$2+@2$2::...::... : @3$2=@1$2+@2$2::... : @3$2=@1$2+@2$2::... #+tblfm: ... #+tblfm: ... #+tblfm: ... may be more intrusive, but also more consistent with #+text: and #+headers: keywords. But maybe generalizing the #+begin_xxx syntax for *all* #+xxx keywords. This would make the current org-internals-oriented/content-oriented difference between #+xxx and #+begin_xxx obsolete I suggest to avoid such a thing. Here are a few, more or less valid, reasons: - That distinction is useful for the user (clear separation between contents and Org control). - It would penalize usage of special blocks. - The need is localized to very few keywords: it isn't worth the added complexity. - It would be ugly: no more nice stacking of keywords, but a mix of blocks and keywords, and blocks on top of blocks... Org syntax may not be the prettiest ever, it doesn't deserve that. - It would be a real pain to parse. but this would spare us the cost of new syntax. On the contrary, creating a block for each keyword would mean a lot of new syntax. We currently have 8 types of blocks (not counting dynamic blocks, whose syntax is a bit different), all requiring to be parsed differently: 1. Center blocks, 2. Comment blocks, 3. Example blocks, 4. Export blocks, 5. Quote blocks, 6. Special blocks, 7. Src blocks, 8. Verse blocks. While others may sparingly be added in the future, I don't think introducing scores of them at the same time would help clarifying Org's syntax. Regards, -- Nicolas Goaziou
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
Something that has not been mentioned yet, as a possible background. One nice thing about subtrees (the properties drawer) for control is that they are nicely (essentially lexically) scoped and nested as in many programming languages. One issue with blocks for control is that they are ambiguously scoped. - It isn't immediately clear whether they apply to the whole file or below the block. + If they apply to the whole file, it can be confusing to have them hidden in some subtree but have global effect. Moving a subtree into the file can surprisingly change state for all other subtrees. + If they apply below the block, and you sort subtrees, those that used to be above or below surprisingly change state. Of course those who work on a file basis still need some way of specifying control for the file. And that can be at the top of the file. I am not saying there should be no way to do that. Just pointing out something not yet mentioned in these threads. Maybe scoping is one reason underlying the unease some have with using blocks for control where there is no equivalent subtree option. I avoid file-level operations partly for that reason. === One interesting possibility is to have a dedicated top-level entry for all file-level control purposes. Then it's clear where everything should go, and syntax can even follow the subtree syntax. However, that might be too radical for this discussion. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com === Bigotry against people with serious diseases is still bigotry.
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
A followup on my second point. On 2011-11-02, Samuel Wales samolog...@gmail.com wrote: === One interesting possibility is to have a dedicated top-level entry for all file-level control purposes. Then it's clear where everything should go, and syntax can even follow the subtree syntax. Thus, for example, a tag on that entry becomes a file tag. To understand file-level syntax, you only need to understand tags and property drawers as usual. There is no need to RTFM the syntax for how to do a file-level operation, because you already know it for subtrees. However, that might be too radical for this discussion. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com === Bigotry against people with serious diseases is still bigotry.
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: For the sake of consistency, I would suggest to drop the export back-end relative keywords. #+html: and #+latex: are indeed disturbing exceptions to the rule. They are also not so convenient (a net gain of 2 lines). Why not. But let's not break backward compatibility just for the sake of consistency. 2) Cumulative properties? Here is a suggestion: use a syntaxe like #+var: foo 1 There is also #+bind:, whose purpose is close enough. Indeed. Eric, would it be possible to use #+bind foo 1 instead of #+property var foo=1 ? 3) Wrapping/folding long #+xxx lines? This is an independant request -- see Robert McIntyre's recent question on the list. The problem is that fill-paragraph on long #+xxx lines breaks the line into comment lines, which is wrong. Filling like this: #+TBLFM: @3$1=@1$1+@2$1::@3$2=@1$2+@2$2::...::... : @3$2=@1$2+@2$2::... : @3$2=@1$2+@2$2::... #+tblfm: ... #+tblfm: ... #+tblfm: ... Not very elegant, but perhaps more efficient/consistent. But maybe generalizing the #+begin_xxx syntax for *all* #+xxx keywords. This would make the current org-internals-oriented/content-oriented difference between #+xxx and #+begin_xxx obsolete I suggest to avoid such a thing. Here are a few, more or less valid, reasons: - That distinction is useful for the user (clear separation between contents and Org control). - It would penalize usage of special blocks. - The need is localized to very few keywords: it isn't worth the added complexity. - It would be ugly: no more nice stacking of keywords, but a mix of blocks and keywords, and blocks on top of blocks... Org syntax may not be the prettiest ever, it doesn't deserve that. - It would be a real pain to parse. Well, I agree with most of the reasons. Glad you stated them clearly. but this would spare us the cost of new syntax. On the contrary, creating a block for each keyword would mean a lot of new syntax. We currently have 8 types of blocks (not counting dynamic blocks, whose syntax is a bit different), all requiring to be parsed differently: 1. Center blocks, 2. Comment blocks, 3. Example blocks, 4. Export blocks, 5. Quote blocks, 6. Special blocks, 7. Src blocks, 8. Verse blocks. I'm not sure what do you mean by requiring to be parsed differently. Can you explain it? I understand they should be treated differently by the exporters, but I don't understand why they would need to be parsed differently. My idea was to avoid parsing both #+html and #+begin_html. And that #+begin_xxx syntax is already available for folding, which is a feature we might want for #+text and keywords like that. I would suggest this rule: #+begin_ is always for _content_ while #+keyword is always for internals that are removed when exporting. #+text, #+html, #+LaTeX are a few exception I can think of. Best, -- Bastien
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
Dear Samuel, I like the way you frame the issue and the solution you are sketching. I am not fund of a dedicated top-level entry for all file-level control purposes because it transforms the ambiguity about keywords' scope into an ambiguity about structure: IMHO a subtree should never be something that you always want to remove when exporting. But allowing a top-level :PROPERTIES: drawer with properties whose scope is the entire file looks like a good idea to me. How other would feel about this? -- Bastien
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
On 10/31/11 10:36 PM, Eric Schulte wrote: 4. My own idea of allowing any defined property to be passed as an argument to src blocks (which would require some changes to how Babel reads its :var header args). I do see how this approach could be powerful, however I fear both the size of the change and the potential negative consequences of combining the property and variable name spaces. Well, you would know better than me on both scores, so I'll stop pushing. Thanks for considering it. Yours, Christian
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
Hello, Eric Schulte schulte.e...@gmail.com writes: Nicolas Goaziou n.goaz...@gmail.com writes: Well, what about: #+property: :var foo=1 #+property: :var bar=2 #+property: :var baz=3 #+property: :var qux=4 Unfortunately this won't work, the final value of the var property will be qux=4 rather than foo=1, bar=2, baz=3, qux=4. I know that it won't work, as #+begin_property didn't work before you introduced it. The idea is to make that work instead (with or without the colons in front of var). I would say that the block is defining an keyword, but yes, I suppose we've never had a multi-line keyword definition structure. I differentiate keywords and blocks from their usage. As such, blocks are not defining a keyword. They're not even in the same league. Along these lines I would also like to allow TBLFM lines to be broken over multiple lines, as I often find myself right-scrolling in a buffer to find equations in large spreadsheets. I wonder if there would be a general solution to allow *all* #keyword+ lines to have a block equivalent. The solution I implemented in my document on Org syntax is to create two keyword's families: cumulative and dual. Belonging to the first one means a keyword accumulates its values on multiple calls instead of replacing them. That's how I parse #+headers: or #+attr_latex lines, for example. The second one allows the keyword to have a secondary, optional, value, in square brackets. This is useful for keywords like #+results:, which can include an hash value like #+results[hash-string]: keyword-value. Typically, what is required here is to add #+property: to the cumulative family. Thus, #+property: var foo=1 #+property: var bar=2 is exactly the same as #+property: var foo=1 var bar=2. Also, make sure var assignations accumulate too. I don't know how #+text: works, but with #+header: the order of the blocks is not important, i.e., #+headers: :var a=1 #+headers: :cache a=2 is equal to #+headers: :cache a=2 #+headers: :var a=1 but the same is not true for #+PROPERTY: var foo=1, #+PROPERTY+: bar=2 and #+PROPERTY+: bar=2 #+PROPERTY: var foo=1, Because, again, #+property+: isn't a great idea. Here, #+headers: accumulates its values. Make the same for #+property: and we're all set. It is desirable to have a logic behind syntax, and to always refer to it. Thus, is is desirable to separate syntax used for contents from syntax used for Org control. It's very different from things on a single line vs things on multiple lines. Sure, but to play devils (or my own) advocate, I would say that simplicity is important and blocks for multi-line content is a simpler rule than blocks for formatting of multi-line content, and for naming multi-line data, the second being the case with code and example blocks. What? Blocks do not name anything. In the case of code and example blocks, you specify Org how to format/understand the contents, like any other block. You use #+name: to name them. Again, the rule is simple: blocks are directly related to contents, keywords aren't. Corollary is: no block with only options and no contents. My goal here is to find the most natural solution which conforms to Org-modes design as well as possible, I just don't know what that would be... We share the same goal. Regards, -- Nicolas Goaziou
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
Correcting myself, Typically, what is required here is to add #+property: to the cumulative family. Thus, #+property: var foo=1 #+property: var bar=2 is exactly the same as #+property: var foo=1 var bar=2. Also, make sure var assignations accumulate too. I don't think #+property: should belong to a cumulative family of keywords. But Babel var keyword definitely should. Thus, the idea stays the same: on multiple var calls, accumulate values instead of replacing them (unless, obviously, the variables has already been assigned a value before).
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
Nicolas Goaziou n.goaz...@gmail.com writes: Correcting myself, Typically, what is required here is to add #+property: to the cumulative family. Thus, #+property: var foo=1 #+property: var bar=2 is exactly the same as #+property: var foo=1 var bar=2. Also, make sure var assignations accumulate too. I don't think #+property: should belong to a cumulative family of keywords. But Babel var keyword definitely should. Thus, the idea stays the same: on multiple var calls, accumulate values instead of replacing them (unless, obviously, the variables has already been assigned a value before). This was one of the proposed options to solve this problem, namely introduce a list of properties whose value accumulates rather than is replaced. Since the property list data structure only allows each key to appear once, the accumulation would necessarily occur on the value side, so assuming var is an accumulating property, then #+property: var foo=1 #+property: var bar=2 would result in `org-file-properties' having the following value ((var . foo=1 bar=1)) Which with some changes in the code-block side code could be used by code blocks to assign multiple variables. I went with changing property syntax rather than internal behavior because I am not overly familiar with properties or the code with which they were implemented and I felt (probably incorrectly) that this would be a less dramatic change to Org-mode. I'm happy to work up a solution along the lines suggested above, which would introduce a variable like `org-accumulating-properties' or some-such which would default to only holding the var property name Best -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
Eric Schulte schulte.e...@gmail.com writes: This was one of the proposed options to solve this problem, namely introduce a list of properties whose value accumulates rather than is replaced. Since the property list data structure only allows each key to appear once, the accumulation would necessarily occur on the value side, so assuming var is an accumulating property, then #+property: var foo=1 #+property: var bar=2 would result in `org-file-properties' having the following value ((var . foo=1 bar=1)) Which with some changes in the code-block side code could be used by code blocks to assign multiple variables. I went with changing property syntax rather than internal behavior because I am not overly familiar with properties or the code with which they were implemented and I felt (probably incorrectly) that this would be a less dramatic change to Org-mode. I'm happy to work up a solution along the lines suggested above, which would introduce a variable like `org-accumulating-properties' or some-such which would default to only holding the var property name That sounds way better to me. It's just a matter of modifying the following part in `org-set-regexps-and-options'. #+begin_src emacs-lisp ((equal key PROPERTY) (when (string-match \\(\\S-+\\)\\s-+\\(.*\\) value) (push (cons (match-string 1 value) (match-string 2 value)) props))) #+end_src If we want to be a bit more future-proof on that side, we may even refine the `org-accumulating-properties' idea by making it an `org-accumulated-properties-alist' where key is property's name and value a symbol describing how they are accumulated. That symbol could be, for example `space', `comma', `newline', `consed'. Regards, -- Nicolas Goaziou
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
Nicolas Goaziou n.goaz...@gmail.com writes: Eric Schulte schulte.e...@gmail.com writes: This was one of the proposed options to solve this problem, namely introduce a list of properties whose value accumulates rather than is replaced. Since the property list data structure only allows each key to appear once, the accumulation would necessarily occur on the value side, so assuming var is an accumulating property, then #+property: var foo=1 #+property: var bar=2 would result in `org-file-properties' having the following value ((var . foo=1 bar=1)) Which with some changes in the code-block side code could be used by code blocks to assign multiple variables. I went with changing property syntax rather than internal behavior because I am not overly familiar with properties or the code with which they were implemented and I felt (probably incorrectly) that this would be a less dramatic change to Org-mode. I'm happy to work up a solution along the lines suggested above, which would introduce a variable like `org-accumulating-properties' or some-such which would default to only holding the var property name That sounds way better to me. It's just a matter of modifying the following part in `org-set-regexps-and-options'. #+begin_src emacs-lisp ((equal key PROPERTY) (when (string-match \\(\\S-+\\)\\s-+\\(.*\\) value) (push (cons (match-string 1 value) (match-string 2 value)) props))) #+end_src If we want to be a bit more future-proof on that side, we may even refine the `org-accumulating-properties' idea by making it an `org-accumulated-properties-alist' where key is property's name and value a symbol describing how they are accumulated. That symbol could be, for example `space', `comma', `newline', `consed'. Beautiful, The attached patch implements this idea with an alist as you specify above. If we can reach some sort of agreement that this is the best way forward I will revert the property blocks and add this patch. Unfortunately I don't know what constitutes agreement, or who the vested interest holders are in this sort of decision. I would be nice if Carsten or Bastien could weigh in. Cheers -- Eric As an aside discussions like this are part of why I really enjoy working on Org-mode. From 2496eec5ad79c7e4e4f3804efb1bbce17f913704 Mon Sep 17 00:00:00 2001 From: Eric Schulte schulte.e...@gmail.com Date: Tue, 1 Nov 2011 10:56:36 -0600 Subject: [PATCH] Allow some properties to accumulate (see `org-accumulated-properties-alist'). The default value of this new variable is '((var . , )) resulting in the following behavior #+property: var foo=1 #+property: var bar=2 #+begin_src emacs-lisp (+ foo bar) #+end_src #+results: : 3 * lisp/org.el (org-accumulated-properties-alist): Adding an alist which specifies which properties may be accumulated and how. (org-set-regexps-and-options): Make use of accumulating properties when collecting said. --- lisp/org.el | 28 ++-- 1 files changed, 26 insertions(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 318ccfd..b34d274 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -4431,6 +4431,22 @@ in the #+STARTUP line, the corresponding variable, and the value to set this variable to if the option is found. An optional forth element PUSH means to push this value onto the list in the variable.) +(defcustom org-accumulated-properties-alist + '((var . , )) + Alist of properties whose values should accumulate rather than overwrite. +Each element of this alist should include both a string property +name as well as the string connector used to join multiple values +for this property. So for example using the default value of +this list which associates \var\ with \, \, the following +Org-mode text, + + #+PROPERTY: var foo=1 + #+PROPERTY: var bar=2 + +will result in the following being added to `org-file-properties'. + + '(\var\ . \foo=1, bar=2\)) + (defun org-set-regexps-and-options () Precompute regular expressions for current buffer. (when (eq major-mode 'org-mode) @@ -4492,8 +4508,16 @@ means to push this value onto the list in the variable.) (setq prio (org-split-string value +))) ((equal key PROPERTY) (when (string-match \\(\\S-+\\)\\s-+\\(.*\\) value) - (push (cons (match-string 1 value) (match-string 2 value)) - props))) + (let* ((prop (match-string 1 value)) + (value (match-string 2 value)) + (str (cdr (assoc prop org-accumulated-properties-alist))) + (existing (cdr (assoc prop props + (if (and str existing) + (setq props (cons (cons prop (concat existing str value)) + (org-remove-if (lambda (p) + (string= (car p) prop)) + props))) + (push (cons prop value) props) ((equal key FILETAGS) (when (string-match \\S- value) (setq ftags -- 1.7.4.1 Regards, -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
On 11/1/11 5:58 PM, Eric Schulte wrote: so assuming var is an accumulating property, then #+property: var foo=1 #+property: var bar=2 would result in `org-file-properties' having the following value ((var . foo=1 bar=1)) Given this: --- #+property: var foo=1 #+property: var bar=2 * Heading :PROPERTIES: :var: foo=3 :END: --- Would it result in ((var . foo=3 bar=2))? Yours, Christian
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
Christian Moe m...@christianmoe.com writes: On 11/1/11 5:58 PM, Eric Schulte wrote: so assuming var is an accumulating property, then #+property: var foo=1 #+property: var bar=2 would result in `org-file-properties' having the following value ((var . foo=1 bar=1)) Given this: --- #+property: var foo=1 #+property: var bar=2 * Heading :PROPERTIES: :var: foo=3 :END: --- Would it result in ((var . foo=3 bar=2))? Good catch Christian, I get the following behavior, currently seems the property-block specification overwrites the global property. I'll have to update my patch to append at the subheading level as well. #+property: var foo=1 #+property: var bar=2 #+begin_src emacs-lisp (+ foo bar) #+end_src #+results: : 3 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=1, bar=2 * heading :PROPERTIES: :var: foo=4 :END: #+begin_src emacs-lisp foo #+end_src #+results: : 4 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=4 As for variable handling, I think the solution is to ensure that on the code-block side of things, a var string like foo=3, bar=2, foo=1 results in, foo=1 bar=2 that is, subtree variable definitions will pre-empty earlier definitions of the same variable.. Best -- Eric Yours, Christian -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
On 11/1/11 8:02 PM, Eric Schulte wrote: As for variable handling, I think the solution is to ensure that on the code-block side of things, a var string like foo=3, bar=2, foo=1 results in, foo=1 bar=2 that is, subtree variable definitions will pre-empty earlier definitions of the same variable.. Yes, that sounds like the way to go. My previous message implied that the var string should only contain unique variable names, but I see that that would be needlessly complicated. This is an interesting approach; I like it better than the property block. I'm sure we will think of other useful applications for cumulative properties, too (conversely, there'll probably be some side effect that will turn around and bite us at some point, though I can't think what it would be). Yours, Christian
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
Christian Moe m...@christianmoe.com writes: On 11/1/11 8:02 PM, Eric Schulte wrote: As for variable handling, I think the solution is to ensure that on the code-block side of things, a var string like foo=3, bar=2, foo=1 results in, foo=1 bar=2 that is, subtree variable definitions will pre-empty earlier definitions of the same variable.. Yes, that sounds like the way to go. My previous message implied that the var string should only contain unique variable names, but I see that that would be needlessly complicated. This is an interesting approach; I like it better than the property block. Me too. I'm sure we will think of other useful applications for cumulative properties, too (conversely, there'll probably be some side effect that will turn around and bite us at some point, though I can't think what it would be). Hopefully more of the former and less of the later. Attached is a new patch, which handles subtree inheritance appropriately, resulting in the following behavior. #+property: var foo=1 #+property: var bar=2 #+begin_src emacs-lisp (+ foo bar) #+end_src #+results: : 3 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=1, bar=2 * heading :PROPERTIES: :var: foo=7 :END: #+begin_src emacs-lisp foo #+end_src #+results: : 7 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=1, bar=2, foo=7 Thanks -- Eric From ff3330193da27a6b0dcf4be92ed54424040ddaec Mon Sep 17 00:00:00 2001 From: Eric Schulte schulte.e...@gmail.com Date: Tue, 1 Nov 2011 10:56:36 -0600 Subject: [PATCH] Allow some properties to accumulate (see `org-accumulated-properties-alist'). The default value of this new variable is '((var . , )) resulting in the following behavior #+property: var foo=1 #+property: var bar=2 #+begin_src emacs-lisp (+ foo bar) #+end_src #+results: : 3 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=1, bar=2 * heading :PROPERTIES: :var: foo=7 :END: #+begin_src emacs-lisp foo #+end_src #+results: : 7 #+begin_src emacs-lisp (org-entry-get (point) var t) #+end_src #+results: : foo=1, bar=2, foo=7 * lisp/org.el (org-accumulated-properties-alist): Adding an alist which specifies which properties may be accumulated and how. (org-set-regexps-and-options): Make use of accumulating properties when collecting said. (org-property-from-plists): Return the (possibly accumulated) value of property from plists. (org-entry-get-with-inheritance): Inherit accumulated properties appropriately. --- lisp/org.el | 52 ++-- 1 files changed, 46 insertions(+), 6 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 318ccfd..2fe8d92 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -4431,6 +4431,22 @@ in the #+STARTUP line, the corresponding variable, and the value to set this variable to if the option is found. An optional forth element PUSH means to push this value onto the list in the variable.) +(defcustom org-accumulated-properties-alist + '((var . , )) + Alist of properties whose values should accumulate rather than overwrite. +Each element of this alist should include both a string property +name as well as the string connector used to join multiple values +for this property. So for example using the default value of +this list which associates \var\ with \, \, the following +Org-mode text, + + #+PROPERTY: var foo=1 + #+PROPERTY: var bar=2 + +will result in the following being added to `org-file-properties'. + + '(\var\ . \foo=1, bar=2\)) + (defun org-set-regexps-and-options () Precompute regular expressions for current buffer. (when (eq major-mode 'org-mode) @@ -4492,8 +4508,13 @@ means to push this value onto the list in the variable.) (setq prio (org-split-string value +))) ((equal key PROPERTY) (when (string-match \\(\\S-+\\)\\s-+\\(.*\\) value) - (push (cons (match-string 1 value) (match-string 2 value)) - props))) + (let* ((prp (match-string 1 value)) + (val (match-string 2 value)) + (new (org-property-from-plists + prp `((,prp . ,val)) props))) + (setq props (cons (cons prp new) +(org-remove-if (lambda (p) (string= (car p) prp)) + props)) ((equal key FILETAGS) (when (string-match \\S- value) (setq ftags @@ -14170,6 +14191,24 @@ no match, the marker will point nowhere. Note that also `org-entry-get' calls this function, if the INHERIT flag is set.) +(defun org-property-from-plists (property rest plists) + Return PROPERTY from PLISTS respecting `org-accumulated-properties-alist'. + (flet ((until (fn lst) (when (not (null lst)) + (or (funcall fn (car lst)) + (funcall fn (cdr lst)) +(let ((str (cdr (assoc property org-accumulated-properties-alist + (if str + (let (result) + (mapc
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, I just noticed that commit (8354fd9e0f5fff04665b2272fff6376b15ec0225). Could we talk about it before pushing it, a few days before the release? I am a bit worried about the new block types being introduced recently. Some may be justified, I don't know yet, but #+begin_property definitely isn't. By looking at the Org syntax. what appears clearly is that Org blocks are used for contents formatting. Center blocks, quote blocks, verse blocks, special blocks, example blocks, export blocks, even src blocks (even though these blocks may be used for very different things, they exist primarily to display source code)... there's no exception. On the other hand, Org internals are controlled through keywords, property drawers, and options on blocks. As #+begin_property block isn't about contents. I can't see any reason for it to exist under this shape. So, again, can we discuss about another approach that would not break the logic behind Org's syntax? I don't fully grasp the problem it tries to solve, but what's wrong with, for example, #+property: var multiple couples? What's wrong with :var_list: x=1,y=3,z=4 in a property drawer? What's wrong with #+header: :var x=1, y=2, z=3 just above the source block? As your already know, #+header can span already on multiple lines. Hoping we can find a more elegant solution, The only problem with a single #+PROPERTY: line is that this line could become unreadably long. By allowing such an entry to span multiple lines it becomes feasible to chain together many variables into a single property. Another approach which is easily implementable would be to use syntax like the following... #+PROPERTY: var foo=1, #+PROPERTY+: bar=2, #+PROPERTY+: baz=3, #+PROPERTY+: qux=4 #+begin_src emacs-lisp (+ foo bar baz qux) #+end_src #+results: : 10 Although I originally switched from the above to the implemented because I thought that using a block would be more consistent with Org-mode syntax. Also, the above is undesirable in its requires the PROPERTY+ lines to care about their position in the Org-mode file, which isn't normally the case. I think of #+FOO: lines as containers for anything that fits on a single line, and as blocks as containers for anything that requires a line break, e.g., #+HTML and #+BEGIN_HTML/#+END_HTML. I didn't realize that there was an extra semantics of blocks as formatting, and I'm not sure if such an association is desirable or intentional. Best -- Eric Regards, -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
Eric Schulte schulte.e...@gmail.com writes: The only problem with a single #+PROPERTY: line is that this line could become unreadably long. By allowing such an entry to span multiple lines it becomes feasible to chain together many variables into a single property. Another approach which is easily implementable would be to use syntax like the following... #+PROPERTY: var foo=1, #+PROPERTY+: bar=2, #+PROPERTY+: baz=3, #+PROPERTY+: qux=4 Well, what about: #+begin_src org #+property: :var foo=1 #+property: :var bar=2 #+property: :var baz=3 #+property: :var qux=4 #+end_src Sure, we repeat :var more times, but at least, it's consistent with the rest of Org. Although I originally switched from the above to the implemented because I thought that using a block would be more consistent with Org-mode syntax. No, as I said, no block has ever controlled Org internals. That's a job for keywords and property drawers. Also, the above is undesirable in its requires the PROPERTY+ lines to care about their position in the Org-mode file, which isn't normally the case. Yes, #+property+: would be atypical in that situation. I think of #+FOO: lines as containers for anything that fits on a single line, and as blocks as containers for anything that requires a line break, e.g., #+HTML and #+BEGIN_HTML/#+END_HTML. That comparison with #+html and #+begin_html doesn't hold as most #+keyword: syntax don't have an equivalent block #+begin_keyword, and the other way. Look again at every block type in Org, and see if there's any equivalent use of the #+begin_property you're introducing. I don't think so. Moreover, some keywords can be repeated on multiple lines. Think about #+text: before first headline, or #+header: before a src block. So, clearly, #+keyword: isn't just about things that must fit on a single line. Also, you don't really need a line break here, since you will eventually parse the values line by line anyway, and not as a block or a paragraph. You want to add syntactic sugar. There's nothing wrong with it though, but not everyone appreciate aspartame ;) I didn't realize that there was an extra semantics of blocks as formatting, and I'm not sure if such an association is desirable or intentional. It is desirable to have a logic behind syntax, and to always refer to it. Thus, is is desirable to separate syntax used for contents from syntax used for Org control. It's very different from things on a single line vs things on multiple lines. Regards, -- Nicolas Goaziou
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
Hi, Having followed the thread on Babel and properties after the removal of the #+BABEL headers, I understand the motivation for introducing this. But I share Nicolas' feelings that a property block doesn't rhyme with existing usage of blocks and properties. There were many other ideas that came up: 1. PROPERTY+ lines (as discussed in Eric's message above). 2. A similar approach to the table formula editor (C-c ') for properties. 3. Allowing some properties to accumulate values, in particular making the :var: property for Babel blocks cumulative (slightly different versions suggested by Eric and Darlan; either would require some changes to Org's property handling), and 4. My own idea of allowing any defined property to be passed as an argument to src blocks (which would require some changes to how Babel reads its :var header args). Solutions 1-2 would solve the long lines problem. Solutions 2-4 would avoid introducing new syntax (#+BEGIN_PROPERTY or #+PROPERTY+) largely to make up for having removed old syntax (#+BABEL). Solutions 3-4 would have wide-ranging effects and would need some careful study, but I think the advantages might outweigh the risks. Yours, Christian
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
On 10/31/11 9:49 PM, Nicolas Goaziou wrote: #+begin_src org #+property: :var foo=1 #+property: :var bar=2 #+property: :var baz=3 #+property: :var qux=4 #+end_src Two problems: 1) You need to drop the colons before var. 2) The outcome is not what you expect. #+property: var foo=1 #+property: var bar=2 #+property: var baz=3 #+property: var qux=4 #+begin_src perl :results output print foo is $foo, bar is $bar, baz is $baz, qux is $qux #+end_src #+results: : foo is 1, bar is , baz is , qux is Because as things currently work, further assignments to the same property (var) by subsequent #+PROPERTY lines are ignored. (Whereas further assignments to the same property in property drawers further down an outline tree will `overwrite' assignments higher up.) Yours, Christian
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
Nicolas Goaziou n.goaz...@gmail.com writes: Eric Schulte schulte.e...@gmail.com writes: The only problem with a single #+PROPERTY: line is that this line could become unreadably long. By allowing such an entry to span multiple lines it becomes feasible to chain together many variables into a single property. Another approach which is easily implementable would be to use syntax like the following... #+PROPERTY: var foo=1, #+PROPERTY+: bar=2, #+PROPERTY+: baz=3, #+PROPERTY+: qux=4 Well, what about: #+property: :var foo=1 #+property: :var bar=2 #+property: :var baz=3 #+property: :var qux=4 Sure, we repeat :var more times, but at least, it's consistent with the rest of Org. Unfortunately this won't work, the final value of the var property will be qux=4 rather than foo=1, bar=2, baz=3, qux=4. Although I originally switched from the above to the implemented because I thought that using a block would be more consistent with Org-mode syntax. No, as I said, no block has ever controlled Org internals. That's a job for keywords and property drawers. I would say that the block is defining an keyword, but yes, I suppose we've never had a multi-line keyword definition structure. Also, the above is undesirable in its requires the PROPERTY+ lines to care about their position in the Org-mode file, which isn't normally the case. Yes, #+property+: would be atypical in that situation. I think of #+FOO: lines as containers for anything that fits on a single line, and as blocks as containers for anything that requires a line break, e.g., #+HTML and #+BEGIN_HTML/#+END_HTML. That comparison with #+html and #+begin_html doesn't hold as most #+keyword: syntax don't have an equivalent block #+begin_keyword, Along these lines I would also like to allow TBLFM lines to be broken over multiple lines, as I often find myself right-scrolling in a buffer to find equations in large spreadsheets. I wonder if there would be a general solution to allow *all* #keyword+ lines to have a block equivalent. and the other way. Look again at every block type in Org, and see if there's any equivalent use of the #+begin_property you're introducing. I don't think so. agreed Moreover, some keywords can be repeated on multiple lines. Think about #+text: before first headline, or #+header: before a src block. So, clearly, #+keyword: isn't just about things that must fit on a single line. I don't know how #+text: works, but with #+header: the order of the blocks is not important, i.e., #+headers: :var a=1 #+headers: :cache a=2 is equal to #+headers: :cache a=2 #+headers: :var a=1 but the same is not true for #+PROPERTY: var foo=1, #+PROPERTY+: bar=2 and #+PROPERTY+: bar=2 #+PROPERTY: var foo=1, Also, you don't really need a line break here, since you will eventually parse the values line by line anyway, and not as a block or a paragraph. You want to add syntactic sugar. There's nothing wrong with it though, but not everyone appreciate aspartame ;) Yes, if you dig way back into this thread you'll see the motivation, basically there are times when a user will want to specify *many* variables in a single property specification. If there is a more natural syntax I am very open to suggestions. I didn't realize that there was an extra semantics of blocks as formatting, and I'm not sure if such an association is desirable or intentional. It is desirable to have a logic behind syntax, and to always refer to it. Thus, is is desirable to separate syntax used for contents from syntax used for Org control. It's very different from things on a single line vs things on multiple lines. Sure, but to play devils (or my own) advocate, I would say that simplicity is important and blocks for multi-line content is a simpler rule than blocks for formatting of multi-line content, and for naming multi-line data, the second being the case with code and example blocks. My goal here is to find the most natural solution which conforms to Org-modes design as well as possible, I just don't know what that would be... Cheers -- Eric Regards, -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] About commit named Allow multi-line properties to be specified in property blocks
4. My own idea of allowing any defined property to be passed as an argument to src blocks (which would require some changes to how Babel reads its :var header args). I do see how this approach could be powerful, however I fear both the size of the change and the potential negative consequences of combining the property and variable name spaces. -- Eric Schulte http://cs.unm.edu/~eschulte/
