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
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
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
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
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
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
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:
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
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
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
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
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
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
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+ ,
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
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
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.
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
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,
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
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
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
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
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
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.
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
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
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
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
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
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.
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
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,
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
*
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:
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
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
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,
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
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
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
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
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
57 matches
Mail list logo
