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
On Tue, Nov 15, 2011 at 5:00 PM, Eric Schulte wrote:
> Rainer M Krug 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-mod
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 abilit
Torsten Wagner 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
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?
Torsten
Rainer M Krug 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 mast
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 writes:
> >
> >> On Tue, Nov 8, 2011 at 11:53
Hi Eric,
Eric Schulte wrote:
> Rainer M Krug writes:
>
>> On Tue, Nov 8, 2011 at 11:53 PM, Eric Schulte 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
>>> >
>>>
Hi Eric,
On 2011-11-03, Eric Schulte 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
On Wed, Nov 9, 2011 at 5:12 PM, Eric Schulte wrote:
> Rainer M Krug writes:
>
> > On Tue, Nov 8, 2011 at 11:53 PM, Eric Schulte >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
> >> > s
Rainer M Krug writes:
> On Tue, Nov 8, 2011 at 11:53 PM, Eric Schulte 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
>> >
>> >
On Tue, Nov 8, 2011 at 11:53 PM, Eric Schulte 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
> 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 separato
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 speci
>>
>> > 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
>>
>> Doe
>>
>> 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
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
#+
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 com
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 ad
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
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
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
>
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 Mon, Nov 7, 2011 at 11:09 PM, 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?
>
Go for it - looks like a really good way
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
#+result
Darlan Cavalcante Moreira 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 simi
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 ha
On Thu, Nov 3, 2011 at 9:23 PM, Eric Schulte 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 syn
Nicolas Goaziou writes:
> Eric Schulte 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:
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 pro
Eric Schulte 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,
>>>
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 sugg
>
> 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: lin
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
>>
Christian Moe wrote:
> On 11/3/11 2:26 AM, Bastien wrote:
> > Hi Nicolas,
> >
> > Nicolas Goaziou 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
>
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 lin
On 11/3/11 2:26 AM, Bastien wrote:
Hi Nicolas,
Nicolas Goaziou 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
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 so
Hi Nicolas,
Nicolas Goaziou 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 b
A followup on my second point.
On 2011-11-02, Samuel Wales 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,
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
Hello,
Bastien 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
>co
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 a
Christian Moe 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
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 variabl
Christian Moe 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"))
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
Nicolas Goaziou writes:
> Eric Schulte 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 accumul
Eric Schulte 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
Nicolas Goaziou 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 a
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 "#+prope
Hello,
Eric Schulte writes:
> Nicolas Goaziou 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, b
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 cha
>
> 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 conseq
Nicolas Goaziou writes:
> Eric Schulte 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 app
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
#+prop
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
Eric Schulte 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 implementab
Nicolas Goaziou 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 kno
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"
definitel
60 matches
Mail list logo
