[ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Eric Schulte]

Hi,

I have just pushed up a change to the Org-mode git repository which
removes support for #+BABEL lines.  Please use the more general
#+PROPERTIES lines instead.

Best -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Nick Dokos]

Eric Schulte <schulte.eric@gmail.com> wrote:

> I have just pushed up a change to the Org-mode git repository which
> removes support for #+BABEL lines.  Please use the more general
> #+PROPERTIES lines instead.
> 

Coming late to the dance - sorry. I think that's very confusing.
"Property" is an overloaded term in org: we now have the :PROPERTIES:
drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and
plural forms are already pretty bad).  Also, there is the general
concept of properties (the stuff that the property API applies to).

Unless there is an underlying unity of which I'm unaware, I'd strongly
suggest another term - perhaps CODE_BLOCK_HEADER_ARGUMENTS (plus
an easy-template for easy insertion). 

Nick

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Eric Schulte]

Nick Dokos <nicholas.dokos@hp.com> writes:

> Eric Schulte <schulte.eric@gmail.com> wrote:
>
>> I have just pushed up a change to the Org-mode git repository which
>> removes support for #+BABEL lines.  Please use the more general
>> #+PROPERTIES lines instead.
>> 
>
> Coming late to the dance - sorry. I think that's very confusing.
> "Property" is an overloaded term in org: we now have the :PROPERTIES:
> drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and
> plural forms are already pretty bad).

Do the #+PROPERTY and #+PROPERTIES lines have different semantics?

> Also, there is the general concept of properties (the stuff that the
> property API applies to).
>
> Unless there is an underlying unity of which I'm unaware, I'd strongly
> suggest another term - perhaps CODE_BLOCK_HEADER_ARGUMENTS (plus
> an easy-template for easy insertion). 
>

Code blocks already piggy-back off of subtree properties pulling their
header arguments out of the properties specified on the subtree level.
Given that header arguments and properties are already thus interleaved
I believe that properties should be used on the file-wide level as well,
rather than introducing another synonymous keyword which adds no new
functionality.

Does that make sense?

Best -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Nick Dokos]

Eric Schulte <schulte.eric@gmail.com> wrote:

> Nick Dokos <nicholas.dokos@hp.com> writes:
> 
> > Eric Schulte <schulte.eric@gmail.com> wrote:
> >
> >> I have just pushed up a change to the Org-mode git repository which
> >> removes support for #+BABEL lines.  Please use the more general
> >> #+PROPERTIES lines instead.
> >> 
> >
> > Coming late to the dance - sorry. I think that's very confusing.
> > "Property" is an overloaded term in org: we now have the :PROPERTIES:
> > drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and
> > plural forms are already pretty bad).
> 
> Do the #+PROPERTY and #+PROPERTIES lines have different semantics?

I think so: see section 7.1 for a use of the former. AFAICT, the latter
only applies to code block header arguments.

> 
> > Also, there is the general concept of properties (the stuff that the
> > property API applies to).
> >
> > Unless there is an underlying unity of which I'm unaware, I'd strongly
> > suggest another term - perhaps CODE_BLOCK_HEADER_ARGUMENTS (plus
> > an easy-template for easy insertion). 
> >
> 
> Code blocks already piggy-back off of subtree properties pulling their
> header arguments out of the properties specified on the subtree level.
> Given that header arguments and properties are already thus interleaved
> I believe that properties should be used on the file-wide level as well,
> rather than introducing another synonymous keyword which adds no new
> functionality.
> 
> Does that make sense?
> 

Yes, but the #+PROPERTIES line has nothing to do with org properties. It
*only* affects code blocks, no?

Nick

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Sebastien Vauban]

Hi Nick and Eric,

Nick Dokos wrote:
> Eric Schulte <schulte.eric-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Nick Dokos <nicholas.dokos-VXdhtT5mjnY@public.gmane.org> writes:
>> > Eric Schulte <schulte.eric-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >
>> >> I have just pushed up a change to the Org-mode git repository which
>> >> removes support for #+BABEL lines.  Please use the more general
>> >> #+PROPERTIES lines instead.
>> >
>> > Coming late to the dance - sorry. I think that's very confusing.
>> > "Property" is an overloaded term in org: we now have the :PROPERTIES:
>> > drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and
>> > plural forms are already pretty bad).

If you'd have asked me, I would have chosen #+BABEL instead of #+PROPERTIES,
as it made it clear "who" owned those directives, to whom they were targeted.

>> Do the #+PROPERTY and #+PROPERTIES lines have different semantics?
>
> I think so: see section 7.1 for a use of the former. AFAICT, the latter
> only applies to code block header arguments.
>
>> > Also, there is the general concept of properties (the stuff that the
>> > property API applies to).
>> >
>> > Unless there is an underlying unity of which I'm unaware, I'd strongly
>> > suggest another term - perhaps CODE_BLOCK_HEADER_ARGUMENTS (plus
>> > an easy-template for easy insertion). 
>> 
>> Code blocks already piggy-back off of subtree properties pulling their
>> header arguments out of the properties specified on the subtree level.
>> Given that header arguments and properties are already thus interleaved
>> I believe that properties should be used on the file-wide level as well,
>> rather than introducing another synonymous keyword which adds no new
>> functionality.
>> 
>> Does that make sense?

However, I've been convinced by Eric's arguments. The fact you already can mix
BABEL properties in subtree PROPERTIES...

> Yes, but the #+PROPERTIES line has nothing to do with org properties. It
> *only* affects code blocks, no?

But, I guess you're right, Nick: not the other way around.

So, I don't know anymore what to think...

I do well agree that "properties" has not a clear-cut meaning anymore; this is
a very general word.

Now, if I had to choose between #+PROPERTY and #+PROPERTIES, I would favor the
last one, as it is some place where you can stuff many properties -- and to
reflect what's already use for the export options: there you put the "options"
under the OPTIONS "meta-keyword". In the plural form.

Just my 2 cents. Whatever your choice, I'll follow it. And I always prefer to
reduce the number of synonyms, and have just one official form[1].

Best regards,
  Seb

Footnotes:

[1] I have the same "annoying" feelings with #+SOURCE, #+SRCNAME, #+FUNCTION,
#+CALL, #+LOB, and SBE, some of which are interchangeable; some not. I'd prefer
deprecating an old form when a better one is found.

-- 
Sebastien Vauban

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Christian Moe]

Whoa -- before this gets more confusing:

Eric, did you push up a (new, or at least so far undocumented in the 
manual) syntax involving a #+PROPERTIES line, as Nick and Sebastien 
seem to understand you?

Or was #+PROPERTIES just a typo, and you mean using the #+PROPERTY 
line or :PROPERTIES: drawer, as provided in the manual?

Yours,
Christian

(lamenting the demise of the #+BABEL header I'd just recently started 
to use)



On 10/20/11 10:12 PM, Eric Schulte wrote:
> Nick Dokos<nicholas.dokos@hp.com>  writes:
>
>> Eric Schulte<schulte.eric@gmail.com>  wrote:
>>
>>> I have just pushed up a change to the Org-mode git repository which
>>> removes support for #+BABEL lines.  Please use the more general
>>> #+PROPERTIES lines instead.
>>>
>>
>> Coming late to the dance - sorry. I think that's very confusing.
>> "Property" is an overloaded term in org: we now have the :PROPERTIES:
>> drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and
>> plural forms are already pretty bad).
>
> Do the #+PROPERTY and #+PROPERTIES lines have different semantics?
>
>> Also, there is the general concept of properties (the stuff that the
>> property API applies to).
>>
>> Unless there is an underlying unity of which I'm unaware, I'd strongly
>> suggest another term - perhaps CODE_BLOCK_HEADER_ARGUMENTS (plus
>> an easy-template for easy insertion).
>>
>
> Code blocks already piggy-back off of subtree properties pulling their
> header arguments out of the properties specified on the subtree level.
> Given that header arguments and properties are already thus interleaved
> I believe that properties should be used on the file-wide level as well,
> rather than introducing another synonymous keyword which adds no new
> functionality.
>
> Does that make sense?
>
> Best -- Eric
>

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Nick Dokos]

Christian Moe <mail@christianmoe.com> wrote:

> Whoa -- before this gets more confusing:
> 
> Eric, did you push up a (new, or at least so far undocumented in the
> manual) syntax involving a #+PROPERTIES line, as Nick and Sebastien
> seem to understand you?
> 
> Or was #+PROPERTIES just a typo, and you mean using the #+PROPERTY
> line or :PROPERTIES: drawer, as provided in the manual?
> 

Here's the commit log (I think it reflects the code changes faithfully):

,----
| commit 04a978fde525a442f9de14d1a67783edd5c9cb78
| Author: Eric Schulte <schulte.eric@gmail.com>
| Date:   Thu Oct 20 13:31:20 2011 -0600
| 
|     removing #+BABEL: lines in favor of general #+PROPERTIES: lines
|     
|     * lisp/ob.el (org-babel-params-from-buffer): Removing #+BABEL: lines
|       in favor of general #+PROPERTIES: lines.
|     
|     * doc/org.texi (Buffer-wide header arguments): Removing documentation
|       of the defunct #+BABEL: structure.
`----

So #+BABEL was traded for #+PROPERTIES.

Nick


> Yours,
> Christian
> 
> (lamenting the demise of the #+BABEL header I'd just recently started
> to use)
> 
> 
> 
> On 10/20/11 10:12 PM, Eric Schulte wrote:
> > Nick Dokos<nicholas.dokos@hp.com>  writes:
> >
> >> Eric Schulte<schulte.eric@gmail.com>  wrote:
> >>
> >>> I have just pushed up a change to the Org-mode git repository which
> >>> removes support for #+BABEL lines.  Please use the more general
> >>> #+PROPERTIES lines instead.
> >>>
> >>
> >> Coming late to the dance - sorry. I think that's very confusing.
> >> "Property" is an overloaded term in org: we now have the :PROPERTIES:
> >> drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and
> >> plural forms are already pretty bad).
> >
> > Do the #+PROPERTY and #+PROPERTIES lines have different semantics?
> >
> >> Also, there is the general concept of properties (the stuff that the
> >> property API applies to).
> >>
> >> Unless there is an underlying unity of which I'm unaware, I'd strongly
> >> suggest another term - perhaps CODE_BLOCK_HEADER_ARGUMENTS (plus
> >> an easy-template for easy insertion).
> >>
> >
> > Code blocks already piggy-back off of subtree properties pulling their
> > header arguments out of the properties specified on the subtree level.
> > Given that header arguments and properties are already thus interleaved
> > I believe that properties should be used on the file-wide level as well,
> > rather than introducing another synonymous keyword which adds no new
> > functionality.
> >
> > Does that make sense?
> >
> > Best -- Eric
> >
> 
> 

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Eric Schulte]

Nick Dokos <nicholas.dokos@hp.com> writes:

> Eric Schulte <schulte.eric@gmail.com> wrote:
>
>> Nick Dokos <nicholas.dokos@hp.com> writes:
>> 
>> > Eric Schulte <schulte.eric@gmail.com> wrote:
>> >
>> >> I have just pushed up a change to the Org-mode git repository which
>> >> removes support for #+BABEL lines.  Please use the more general
>> >> #+PROPERTIES lines instead.
>> >> 
>> >
>> > Coming late to the dance - sorry. I think that's very confusing.
>> > "Property" is an overloaded term in org: we now have the :PROPERTIES:
>> > drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and
>> > plural forms are already pretty bad).
>> 
>> Do the #+PROPERTY and #+PROPERTIES lines have different semantics?
>
> I think so: see section 7.1 for a use of the former. AFAICT, the latter
> only applies to code block header arguments.
>

Oh!

Thank you for making this clear, I had assumed that #+PROPERTIES: lines
were an integral part of Org-mode which code block header arguments were
simply making use of.  Having read the section of the info manual you
point out above I see that I was mistaken.  I've just pushed up what I
consider to be a clean implementation.  Put briefly the new behavior is
that "properties may be used to specify header arguments".  More
completely...

1. The #+PROPERTIES: (and #+BABEL:) directives no longer exist.

2. The existing #+PROPERTY: line may now be used to specify values for
   header arguments, e.g.,

   #+PROPERTY: results silent

   would silence all results in the current buffer.

I think this should be simple, easy to remember, and it certainly
cleaned up the code base.  Please let me know what you think of this new
setup.

Thanks -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[suvayu ali]

Hi Eric,

On Thu, Oct 20, 2011 at 11:34 PM, Eric Schulte <schulte.eric@gmail.com> wrote:
> 2. The existing #+PROPERTY: line may now be used to specify values for
>   header arguments, e.g.,
>
>   #+PROPERTY: results silent
>
>   would silence all results in the current buffer.
>

Is the 'results' without a preceding colon or is that a typo?

-- 
Suvayu

Open source is the future. It sets us free.

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Sebastien Vauban]

Hi Eric,

Eric Schulte wrote:
> Nick Dokos <nicholas.dokos-VXdhtT5mjnY@public.gmane.org> writes:
>> Eric Schulte <schulte.eric-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> Nick Dokos <nicholas.dokos-VXdhtT5mjnY@public.gmane.org> writes:
>>> > Eric Schulte <schulte.eric-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> >
>>> >> I have just pushed up a change to the Org-mode git repository which
>>> >> removes support for #+BABEL lines.  Please use the more general
>>> >> #+PROPERTIES lines instead.
>>> >
>>> > Coming late to the dance - sorry. I think that's very confusing.
>>> > "Property" is an overloaded term in org: we now have the :PROPERTIES:
>>> > drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and
>>> > plural forms are already pretty bad).
>>> 
>>> Do the #+PROPERTY and #+PROPERTIES lines have different semantics?
>>
>> I think so: see section 7.1 for a use of the former. AFAICT, the latter
>> only applies to code block header arguments.
>
> Oh!
>
> Thank you for making this clear, I had assumed that #+PROPERTIES: lines
> were an integral part of Org-mode which code block header arguments were
> simply making use of.  Having read the section of the info manual you
> point out above I see that I was mistaken.  I've just pushed up what I
> consider to be a clean implementation.  Put briefly the new behavior is
> that "properties may be used to specify header arguments".  More
> completely...
>
> 1. The #+PROPERTIES: (and #+BABEL:) directives no longer exist.
>
> 2. The existing #+PROPERTY: line may now be used to specify values for
>    header arguments, e.g.,
>
>    #+PROPERTY: results silent
>
>    would silence all results in the current buffer.
>
> I think this should be simple, easy to remember, and it certainly
> cleaned up the code base.  Please let me know what you think of this new
> setup.

I just have one question, as I'm puzzled by the lack of `:' in front of the
"properties": how do we distinguish the argument "value" from the argument
"name"?

For example, how do we translate, in the new syntax,

#+BABEL:    :results output code append

(where `:results' is the "name", and `output', `code' and `append' are
"values")?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Nick Dokos]

Eric Schulte <schulte.eric@gmail.com> wrote:

> ...  I've just pushed up what I
> consider to be a clean implementation.  Put briefly the new behavior is
> that "properties may be used to specify header arguments".  More
> completely...
> 
> 1. The #+PROPERTIES: (and #+BABEL:) directives no longer exist.
> 
> 2. The existing #+PROPERTY: line may now be used to specify values for
>    header arguments, e.g.,
> 
>    #+PROPERTY: results silent
> 
>    would silence all results in the current buffer.
> 
> I think this should be simple, easy to remember, and it certainly
> cleaned up the code base.  Please let me know what you think of this new
> setup.
> 

Other than "colon confusion" (having to specify ``:results silent'' on
the src block header line and ``results silent'' in the #+PROPERTY line
to get the same behavior), this looks better. Not sure what (if
anything) can or should be done about the colons.

Thanks,
Nick

[RFC] Standardized code block keywords

[Eric Schulte]

> [1] I have the same "annoying" feelings with #+SOURCE, #+SRCNAME, #+FUNCTION,
> #+CALL, #+LOB, and SBE, some of which are interchangeable; some not. I'd prefer
> deprecating an old form when a better one is found.

This point of view has been raised previously both on the mailing list
and in the #org-mode IRC chat room.  I think it is time that we decided
as a community what we want to do about the prevalence of code block
synonyms -- we should make this decision before the release of Emacs24
after which syntax will become harder to change.

There are currently a number of instances of synonymous keywords when
dealing with code blocks, specifically.

         named code blocks [1] -- "source" "srcname" "function"
calling external functions [2] -- "call" "lob"
                named data [3] -- "tblname" "resname" "results" "data"

Ideally if we limit each of the above to only one alternative we could
simplify the specification of code blocks in Org-mode making them easier
to learn and use and removing some of the mystery around their syntax.

What does everyone think?

Are there suggestions for the best names for each code block entity
(either in the list or not in the list)?

Are there cases where we want to continue to allow synonyms (e.g., in
named data so that "results" can be used for code block results but
"data" can be used for hand-written data)?

Thanks -- Eric

Footnotes: 
[1] named code blocks

    #+source: foo
    #+begin_src emacs-lisp
      'foo
    #+end_src

    #+srcname: foo
    #+begin_src emacs-lisp
      'foo
    #+end_src

    #+function: foo
    #+begin_src emacs-lisp
      'foo
    #+end_src

[2]  calling external functions

    #+call: foo()

    #+lob: foo()

[3]  named data

    #+data: something
    : something

    #+results: something
    : something

    etc...

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Eric Schulte]

suvayu ali <fatkasuvayu+linux@gmail.com> writes:

> Hi Eric,
>
> On Thu, Oct 20, 2011 at 11:34 PM, Eric Schulte <schulte.eric@gmail.com> wrote:
>> 2. The existing #+PROPERTY: line may now be used to specify values for
>>   header arguments, e.g.,
>>
>>   #+PROPERTY: results silent
>>
>>   would silence all results in the current buffer.
>>
>
> Is the 'results' without a preceding colon or is that a typo?

As with properties specified in :PROPERTIES: blocks under headlines, the
colon is not needed, the above is correct.

Best -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Eric Schulte]

"Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:

> Hi Eric,
>
> Eric Schulte wrote:
>> Nick Dokos <nicholas.dokos@hp.com> writes:
>>> Eric Schulte <schulte.eric@gmail.com> wrote:
>>>> Nick Dokos <nicholas.dokos@hp.com> writes:
>>>> > Eric Schulte <schulte.eric@gmail.com> wrote:
>>>> >
>>>> >> I have just pushed up a change to the Org-mode git repository which
>>>> >> removes support for #+BABEL lines.  Please use the more general
>>>> >> #+PROPERTIES lines instead.
>>>> >
>>>> > Coming late to the dance - sorry. I think that's very confusing.
>>>> > "Property" is an overloaded term in org: we now have the :PROPERTIES:
>>>> > drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and
>>>> > plural forms are already pretty bad).
>>>> 
>>>> Do the #+PROPERTY and #+PROPERTIES lines have different semantics?
>>>
>>> I think so: see section 7.1 for a use of the former. AFAICT, the latter
>>> only applies to code block header arguments.
>>
>> Oh!
>>
>> Thank you for making this clear, I had assumed that #+PROPERTIES: lines
>> were an integral part of Org-mode which code block header arguments were
>> simply making use of.  Having read the section of the info manual you
>> point out above I see that I was mistaken.  I've just pushed up what I
>> consider to be a clean implementation.  Put briefly the new behavior is
>> that "properties may be used to specify header arguments".  More
>> completely...
>>
>> 1. The #+PROPERTIES: (and #+BABEL:) directives no longer exist.
>>
>> 2. The existing #+PROPERTY: line may now be used to specify values for
>>    header arguments, e.g.,
>>
>>    #+PROPERTY: results silent
>>
>>    would silence all results in the current buffer.
>>
>> I think this should be simple, easy to remember, and it certainly
>> cleaned up the code base.  Please let me know what you think of this new
>> setup.
>
> I just have one question, as I'm puzzled by the lack of `:' in front of the
> "properties": how do we distinguish the argument "value" from the argument
> "name"?
>
> For example, how do we translate, in the new syntax,
>
> #+BABEL:    :results output code append
>
> (where `:results' is the "name", and `output', `code' and `append' are
> "values")?
>

The above would become

#+PROPERTY: results output code append

Since only one property may be specified per property line there is no
need for colons.  This mirrors exactly the way the properties are saved
under subtrees in :PROPERTY: blocks.

Multiple lines may be used to specify multiple properties. e.g.,

#+PROPERTY: results silent
#+PROPERTY: cache yes

Best -- Eric

>
> Best regards,
>   Seb

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Eric Schulte]

Nick Dokos <nicholas.dokos@hp.com> writes:

> Eric Schulte <schulte.eric@gmail.com> wrote:
>
>> ...  I've just pushed up what I
>> consider to be a clean implementation.  Put briefly the new behavior is
>> that "properties may be used to specify header arguments".  More
>> completely...
>> 
>> 1. The #+PROPERTIES: (and #+BABEL:) directives no longer exist.
>> 
>> 2. The existing #+PROPERTY: line may now be used to specify values for
>>    header arguments, e.g.,
>> 
>>    #+PROPERTY: results silent
>> 
>>    would silence all results in the current buffer.
>> 
>> I think this should be simple, easy to remember, and it certainly
>> cleaned up the code base.  Please let me know what you think of this new
>> setup.
>> 
>
> Other than "colon confusion" (having to specify ``:results silent'' on
> the src block header line and ``results silent'' in the #+PROPERTY line
> to get the same behavior), this looks better. Not sure what (if
> anything) can or should be done about the colons.
>

I don't know of a good solution for colons.  If we decided to add colons
then the subtree property blocks would become akward, with entries like

** foo
   :PROPERTIES:
   ::results: silent
   :END:

I would say we could look for each value both with and without colons,
but property searches of this nature are slow and doubling the speed
impact simply for allow colon flexibility doesn't seem to be a good
tradeoff.  I think this will just have to be something that users will
need to learn.

Cheers -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Nick Dokos]

Sebastien Vauban <wxhgmqzgwmuf@spammotel.com> wrote:


> I just have one question, as I'm puzzled by the lack of `:' in front of the
> "properties": how do we distinguish the argument "value" from the argument
> "name"?
> 
> For example, how do we translate, in the new syntax,
> 
> #+BABEL:    :results output code append
> 
> (where `:results' is the "name", and `output', `code' and `append' are
> "values")?
> 

#+PROPERTY: results output code append

See the aforementioned sec. 7.1 of the manual. Equivalently,

* foo
  :PROPERTIES:
  :results: output code append
  :END:

That's a consequence of the property syntax. On the code block
header line however, you have to have some purely syntactic
marker to distinguish properties from their values, hence

#+begin_src foo :results output code append :exports both
...

The trick is to think of the colon as a delimited (like a comma)
not as a part of the property name.

Nick

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Nick Dokos]

Eric Schulte <schulte.eric@gmail.com> wrote:

> > Other than "colon confusion" (having to specify ``:results silent'' on
> > the src block header line and ``results silent'' in the #+PROPERTY line
> > to get the same behavior), this looks better. Not sure what (if
> > anything) can or should be done about the colons.
> >
> 
> I don't know of a good solution for colons.  If we decided to add colons
> then the subtree property blocks would become akward, with entries like
> 
> ** foo
>    :PROPERTIES:
>    ::results: silent
>    :END:
> 
> I would say we could look for each value both with and without colons,
> but property searches of this nature are slow and doubling the speed
> impact simply for allow colon flexibility doesn't seem to be a good
> tradeoff.  I think this will just have to be something that users will
> need to learn.
> 

I agree[fn:1]: the point is to simplify the code, not complicate it
*and* slow down everything at the same time.  Maybe the header args
section of the manual can use the "colon as delimiter" method to explain
the equivalent forms and that will suffice.

Nick

Footnotes:

[fn:1] ...but I take some perverse pleasure from the fact that both
Suvayu and Seb asked the question :-)

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Eric Schulte]

Nick Dokos <nicholas.dokos@hp.com> writes:

> Eric Schulte <schulte.eric@gmail.com> wrote:
>
>> > Other than "colon confusion" (having to specify ``:results silent'' on
>> > the src block header line and ``results silent'' in the #+PROPERTY line
>> > to get the same behavior), this looks better. Not sure what (if
>> > anything) can or should be done about the colons.
>> >
>> 
>> I don't know of a good solution for colons.  If we decided to add colons
>> then the subtree property blocks would become akward, with entries like
>> 
>> ** foo
>>    :PROPERTIES:
>>    ::results: silent
>>    :END:
>> 
>> I would say we could look for each value both with and without colons,
>> but property searches of this nature are slow and doubling the speed
>> impact simply for allow colon flexibility doesn't seem to be a good
>> tradeoff.  I think this will just have to be something that users will
>> need to learn.
>> 
>
> I agree[fn:1]: the point is to simplify the code, not complicate it
> *and* slow down everything at the same time.  Maybe the header args
> section of the manual can use the "colon as delimiter" method to explain
> the equivalent forms and that will suffice.
>

I agree, the header argument syntax portion of the documentation could
be made more clear, and I did like you explanation to Seb's email.
Perhaps you could submit a documentation patch? :)

>
> Nick
>
> Footnotes:
>
> [fn:1] ...but I take some perverse pleasure from the fact that both
> Suvayu and Seb asked the question :-)

I noticed that too, and it no doubt means that this same question will
occur to future users.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Suvayu Ali]

On Thu, 20 Oct 2011 15:52:42 -0600
Eric Schulte <schulte.eric@gmail.com> wrote:

> suvayu ali <fatkasuvayu+linux@gmail.com> writes:
> 
> > Hi Eric,
> >
> > On Thu, Oct 20, 2011 at 11:34 PM, Eric Schulte
> > <schulte.eric@gmail.com> wrote:
> >> 2. The existing #+PROPERTY: line may now be used to specify values
> >> for header arguments, e.g.,
> >>
> >>   #+PROPERTY: results silent
> >>
> >>   would silence all results in the current buffer.
> >>
> >
> > Is the 'results' without a preceding colon or is that a typo?
> 
> As with properties specified in :PROPERTIES: blocks under headlines,
> the colon is not needed, the above is correct.
> 

Thanks a lot Eric. I have never used :PROPERTIES: for Babel, hence I
didn't know!

> Best -- Eric
> 

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: [RFC] Standardized code block keywords

[Thomas S. Dye]

Eric Schulte <schulte.eric@gmail.com> writes:

>> [1] I have the same "annoying" feelings with #+SOURCE, #+SRCNAME, #+FUNCTION,
>> #+CALL, #+LOB, and SBE, some of which are interchangeable; some
>> not. I'd prefer
>> deprecating an old form when a better one is found.
>
> This point of view has been raised previously both on the mailing list
> and in the #org-mode IRC chat room.  I think it is time that we decided
> as a community what we want to do about the prevalence of code block
> synonyms -- we should make this decision before the release of Emacs24
> after which syntax will become harder to change.
>
> There are currently a number of instances of synonymous keywords when
> dealing with code blocks, specifically.
>
>          named code blocks [1] -- "source" "srcname" "function"
> calling external functions [2] -- "call" "lob"
>                 named data [3] -- "tblname" "resname" "results" "data"
>
> Ideally if we limit each of the above to only one alternative we could
> simplify the specification of code blocks in Org-mode making them easier
> to learn and use and removing some of the mystery around their syntax.
>
> What does everyone think?
>
> Are there suggestions for the best names for each code block entity
> (either in the list or not in the list)?
>
> Are there cases where we want to continue to allow synonyms (e.g., in
> named data so that "results" can be used for code block results but
> "data" can be used for hand-written data)?
>
> Thanks -- Eric
>
> Footnotes: 
> [1] named code blocks
>
>     #+source: foo
>     #+begin_src emacs-lisp
>       'foo
>     #+end_src
>
>     #+srcname: foo
>     #+begin_src emacs-lisp
>       'foo
>     #+end_src
>
>     #+function: foo
>     #+begin_src emacs-lisp
>       'foo
>     #+end_src
>
> [2]  calling external functions
>
>     #+call: foo()
>
>     #+lob: foo()
>
> [3]  named data
>
>     #+data: something
>     : something
>     #+results: something
>     : something
>
>     etc...

Hi Eric,

named code blocks [1] "source"
calling external functions [2] "call"
named data [3] "object"

My motivation for [3] "object" instead of the suggested alternates is
the hope that it will be possible to name things like lists and
paragraphs (that aren't results or data) and pass these objects to
source code blocks.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [RFC] Standardized code block keywords

[Nick Dokos]

Thomas S. Dye <tsd@tsdye.com> wrote:

> Eric Schulte <schulte.eric@gmail.com> writes:
> 
> >> [1] I have the same "annoying" feelings with #+SOURCE, #+SRCNAME, #+FUNCTION,
> >> #+CALL, #+LOB, and SBE, some of which are interchangeable; some
> >> not. I'd prefer
> >> deprecating an old form when a better one is found.
> >
> > This point of view has been raised previously both on the mailing list
> > and in the #org-mode IRC chat room.  I think it is time that we decided
> > as a community what we want to do about the prevalence of code block
> > synonyms -- we should make this decision before the release of Emacs24
> > after which syntax will become harder to change.
> >
> > There are currently a number of instances of synonymous keywords when
> > dealing with code blocks, specifically.
> >
> >          named code blocks [1] -- "source" "srcname" "function"
> > calling external functions [2] -- "call" "lob"
> >                 named data [3] -- "tblname" "resname" "results" "data"
> >
> > Ideally if we limit each of the above to only one alternative we could
> > simplify the specification of code blocks in Org-mode making them easier
> > to learn and use and removing some of the mystery around their syntax.
> >
> > What does everyone think?
> >
> > Are there suggestions for the best names for each code block entity
> > (either in the list or not in the list)?
> >
> > Are there cases where we want to continue to allow synonyms (e.g., in
> > named data so that "results" can be used for code block results but
> > "data" can be used for hand-written data)?
> >
> > Thanks -- Eric
> >
> > Footnotes: 
> > [1] named code blocks
> >
> >     #+source: foo
> >     #+begin_src emacs-lisp
> >       'foo
> >     #+end_src
> >
> >     #+srcname: foo
> >     #+begin_src emacs-lisp
> >       'foo
> >     #+end_src
> >
> >     #+function: foo
> >     #+begin_src emacs-lisp
> >       'foo
> >     #+end_src
> >
> > [2]  calling external functions
> >
> >     #+call: foo()
> >
> >     #+lob: foo()
> >
> > [3]  named data
> >
> >     #+data: something
> >     : something
> >     #+results: something
> >     : something
> >
> >     etc...
> 
> Hi Eric,
> 
> named code blocks [1] "source"
> calling external functions [2] "call"
> named data [3] "object"
> 
> My motivation for [3] "object" instead of the suggested alternates is
> the hope that it will be possible to name things like lists and
> paragraphs (that aren't results or data) and pass these objects to
> source code blocks.
> 

I disagree with Tom on [1]: it should clearly be "srcname", in analogy
to #+tblname - and also so I don't have to change my files :-} (but see
my question about tblname below).

I agree on [2] "call".

I'm confused by [3] so I will say nothing for now, except to ask some
questions: are we talking about what a human would use to label a piece
of data for consumption by a block (including perhaps the future
possibilities of lists and paragraphs that Tom brought up)? what babel
would use to label a results block (possibly so that it could be
consumed by another block in a chain)? both? would that mean
that #+tblname would go the way of the dodo and that tables would be
labelled with #+data (or #+object or whatever else we come up with)?

Thanks,
Nick

Re: [RFC] Standardized code block keywords

[Christian Moe]

> I disagree with Tom on [1]: it should clearly be "srcname", in analogy
> to #+tblname - and also so I don't have to change my files :-} (but see
> my question about tblname below).

I'll have to change my files, either way. The price one pays for 
inconsistency. But as I've recently learned from Carsten, it should be 
a one-liner in Perl. :-)

For the sake of analogy, I'll cast my vote for SRCNAME, even if SOURCE 
is more aesthetically pleasing.

>
> I agree on [2] "call".

+1

>
> I'm confused by [3] so I will say nothing for now, except to ask some
> questions: are we talking about what a human would use to label a piece
> of data for consumption by a block (including perhaps the future
> possibilities of lists and paragraphs that Tom brought up)? what babel
> would use to label a results block (possibly so that it could be
> consumed by another block in a chain)? both? would that mean
> that #+tblname would go the way of the dodo and that tables would be
> labelled with #+data (or #+object or whatever else we come up with)?

+1 (Confused, too)

I wasn't even aware of #+DATA. Does it do anything TBLNAME and SRCNAME 
don't?

A reason to keep TBLNAME is that it's also used by the spreadsheet 
remote references. If Babel looked for DATA instead, a table that is 
both a remote reference for another spreadsheet and a data source for 
a src block would need both TBLNAME and DATA, which seems redundant.

As for labeling lists and paragraphs, I recall from the list that 
Nicolas Goaziou is working on a generalized way to set captions, 
labels and attributes for various kinds of Org block, as is possible 
now for tables and images. I thought that sounded promising. I don't 
know if he planned for block names, too (currently we have tblname but 
no imgname), but that could make sense. In which case it might be a 
good idea to coordinate.

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Sebastien Vauban]

Hi Eric and Nick,

Eric Schulte wrote:
> Nick Dokos <nicholas.dokos-VXdhtT5mjnY@public.gmane.org> writes:
>> Eric Schulte <schulte.eric-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>>> > Other than "colon confusion" (having to specify ``:results silent'' on
>>> > the src block header line and ``results silent'' in the #+PROPERTY line
>>> > to get the same behavior), this looks better. Not sure what (if
>>> > anything) can or should be done about the colons.
>>> >
>>> 
>>> I don't know of a good solution for colons.  If we decided to add colons
>>> then the subtree property blocks would become akward, with entries like
>>> 
>>> ** foo
>>>    :PROPERTIES:
>>>    ::results: silent
>>>    :END:
>>> 
>>> I would say we could look for each value both with and without colons,
>>> but property searches of this nature are slow and doubling the speed
>>> impact simply for allow colon flexibility doesn't seem to be a good
>>> tradeoff.  I think this will just have to be something that users will
>>> need to learn.
>>
>> [fn:1] ...but I take some perverse pleasure from the fact that both
>> Suvayu and Seb asked the question :-)
>
> I noticed that too, and it no doubt means that this same question will
> occur to future users.

I knew there was no beginning colon in the #+PROPERTY line (and that does not
bother me).

>> For example, how do we translate, in the new syntax,
>>
>> #+BABEL:    :results output code append
>>
>> (where `:results' is the "name", and `output', `code' and `append' are
>> "values")?
>
> The above would become
>
> #+PROPERTY: results output code append
>
> Since only one property may be specified per property line there is no
> need for colons.  This mirrors exactly the way the properties are saved
> under subtrees in :PROPERTY: blocks.
>
> Multiple lines may be used to specify multiple properties. e.g.,
>
> #+PROPERTY: results silent
> #+PROPERTY: cache yes

*But* I did not know it was limited to _one property per line_.

Knowing that:

- there is no confusion at all -- we simply (have to) know that the first word
  is the "name" without colon, and the rest are "values"

- my argument in favor of #+PROPERTIES (over #+PROPERTY) simply falls.

To sum up, I'm perfectly happy with the new choice.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [RFC] Standardized code block keywords

[Torsten Wagner]

Hi,

> Ideally if we limit each of the above to only one alternative we could
> simplify the specification of code blocks in Org-mode making them easier
> to learn and use and removing some of the mystery around their syntax.
>
> What does everyone think?

Just to make it as easy as possible for everyone....
Might it be possible to introduce a small flags like "obsolete" and
"stable" (standard)
Old functions, old syntax, etc., might move first to obsolete before
completely removed...
We could open an older file and if it isn't working, we could try

#+PROPERTY: babel-function-set obsolete

if it works, we have to modify the code, because obviously the code
requires changed to be compatible in the future. However, just for the
moment it is still working. This would give people more time to change
there code accordingly. As murphy law tells us one will notice that
the particular file is broken exact 5 minutes before the meeting with
your boss standing behind you yelling.... print it, print it  ;)

I know git would be perfect to keep the code base frozen for a certain
syntax. However, babel is bundled with org-mode which is bundled with
Emacs. Thus, it might be very difficult to tell people they have to
use org-babel from git with the tag [org-babel_XX] if they want to use
there old style files.  AFAIK org-babel does not even come with a own
version numbering, right?

Alternatively, keep the syntax a little bit longer as it is and create
warning messages to point users to future changes (not sure how much
time left for emacs24)
"Warning: #+lob: in line XX is obsolete, please use #+call: in the
future. (manual-link)"

To make is short, is is possible to introduce changes "slowly"

As for voting:
[1]
#+function: would be what I would expect from other programming
languages. Where an unnamed source code block would be something like
a lambda function.
However, "function" as a term is heavily used in many target languages
too. This makes parsing, reading and discussing a bit difficult. ("I
called the function foo", "Wait, do you call the org-mode function
foo, or the python function foo?")
Thus, I vote for #+srcname similar to #+tblname to make sure about the
difference between org-babel and the target languages.

[2]
#+call:, simply because I never can remember "lob" and the acronym is
something difficult for newbies.

[3]
I tend to  #+results: because it fits more to the entire babel syntax.
However, earlier on the mailing list people were pointing out that one
is going to change "results" for a unknown source block (that was the
reason "data" was introduced).... and I think this is a valid
argument. Maybe "data" and "results" should be both valid if only to
pleasure human thinking. However, if I understood correctly, maybe
data could be changed to be more some type of constant? That is,
#+data: foo can not be changed by a source code block named foo
(because it isn't a "result" but "data") but only by human (as a
"data" input). Does this make sense?

Totti

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Christian Moe]

Hi again,

I can quickly think of two advantages of the late lamented (if only by 
me) #+BABEL header over using properties.

1. Allowing you to specify multiple buffer-wide options on the same 
line (keeping things short), in the same colon :syntax as used in a 
src block header (keeping things consistent and easy to copy back and 
forth). None of this makes a substantive difference.

2. Allowing you to pass multiple buffer-wide arguments with :var. This 
could make a substantive difference in some applications. The 
following will work:

   #+BABEL: :var euro=1.3791 :var salestax=.15

The following will not, since it tries to set the same property:

   #+PROPERTY: var euro=1.3791
   #+PROPERTY: var salestax=.15

If BABEL is dropped for PROPERTY, it would be good for the :var: 
property to support multiple arguments (comma-separated would be good 
for consistency with passing arguments through the SRCNAME). E.g.:

   #+PROPERTY: var euro=1.3791, salestax=.15

I think I'd like this better in any case.

Yours,
Christian


On 10/21/11 9:28 AM, Sebastien Vauban wrote:
>> Multiple lines may be used to specify multiple properties. e.g.,
>>
>> #+PROPERTY: results silent
>> #+PROPERTY: cache yes
>
> *But* I did not know it was limited to _one property per line_.
>
> Knowing that:
>
> - there is no confusion at all -- we simply (have to) know that the first word
>    is the "name" without colon, and the rest are "values"
>
> - my argument in favor of #+PROPERTIES (over #+PROPERTY) simply falls.
>
> To sum up, I'm perfectly happy with the new choice.
>
> Best regards,
>    Seb
>

Re: [RFC] Standardized code block keywords

[Sebastien Vauban]

Hi Nick, Tom, Eric and all,

Nick Dokos wrote:
> Thomas S. Dye <tsd-P0awH739Ni4AvxtiuMwx3w@public.gmane.org> wrote:
>> Eric Schulte <schulte.eric-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>> 
>>>> [1] I have the same "annoying" feelings with #+SOURCE, #+SRCNAME, #+FUNCTION,
>>>> #+CALL, #+LOB, and SBE, some of which are interchangeable; some
>>>> not. I'd prefer deprecating an old form when a better one is found.
>>>
>>> This point of view has been raised previously both on the mailing list
>>> and in the #org-mode IRC chat room. I think it is time that we decided as
>>> a community what we want to do about the prevalence of code block
>>> synonyms -- we should make this decision before the release of Emacs24
>>> after which syntax will become harder to change.

Thanks for tackling this.

>>> There are currently a number of instances of synonymous keywords when
>>> dealing with code blocks, specifically.
>>>
>>>          named code blocks [1] -- "source" "srcname" "function"
>>> calling external functions [2] -- "call" "lob"
>>>                 named data [3] -- "tblname" "resname" "results" "data"
>>>
>>> Ideally if we limit each of the above to only one alternative we could
>>> simplify the specification of code blocks in Org-mode making them easier
>>> to learn and use and removing some of the mystery around their syntax.
>>>
>>> What does everyone think?
>>>
>>> Are there suggestions for the best names for each code block entity
>>> (either in the list or not in the list)?
>>>
>>> Are there cases where we want to continue to allow synonyms (e.g., in
>>> named data so that "results" can be used for code block results but
>>> "data" can be used for hand-written data)?
>>>
>>> Thanks -- Eric
>>>
>>> Footnotes: 
>>> [1] named code blocks
>>>
>>>     #+source: foo
>>>     #+begin_src emacs-lisp
>>>       'foo
>>>     #+end_src
>>>
>>>     #+srcname: foo
>>>     #+begin_src emacs-lisp
>>>       'foo
>>>     #+end_src
>>>
>>>     #+function: foo
>>>     #+begin_src emacs-lisp
>>>       'foo
>>>     #+end_src
>>>
>>> [2]  calling external functions
>>>
>>>     #+call: foo()
>>>
>>>     #+lob: foo()
>>>
>>> [3]  named data
>>>
>>>     #+data: something
>>>     : something
>>>     #+results: something
>>>     : something
>>>
>>>     etc...
>>
>> named code blocks [1] "source"
>> calling external functions [2] "call"
>> named data [3] "object"
>>
>> My motivation for [3] "object" instead of the suggested alternates is the
>> hope that it will be possible to name things like lists and paragraphs
>> (that aren't results or data) and pass these objects to source code blocks.
>
> I disagree with Tom on [1]: it should clearly be "srcname", in analogy
> to #+tblname - and also so I don't have to change my files :-} (but see my
> question about tblname below).

I have low attraction for "function" as this seems too-programming oriented:
IMHO, it's too much minded toward the "results value" aspect of Babel
("functional mode"), and not at all toward the "scripting mode" (shell
scripts, SQL commands).

Moreover, in fact, in such blocks, we don't have executable code per se: just
think at Ledger transactions that I would want to wrap...

    #+srcname: journal
    #+begin_src ledger
    2008/01/03 * ( ) ME
            Assets:Bank:Checking:799997045030	                        550.00 EUR
            Assets:Bank:Transferred

    2008/01/01 * ( ) UNKNOWN-PAYEE
            Assets:Bank:Checking:799997045030	                         21.91 EUR
            Expenses:Unknown
    #+end_src

..., and reuse in a block later (through the Noweb expansion):

    #+srcname: ledger-balance
    #+begin_src ledger :cmdline bal :noweb yes
    <<journal>>
    #+end_src

Though, in this latter case, one could object I could maybe (?) refer them
through the "object" name facility -- I'm referring to point 3 of Tom's
answer, see below.

    Note -- Then, I would loose the language-editing facility. When we create
    an "object" ("results" or "data"), there is no "language" associated,
    hence no ability to edit easily via C-c ', and no correct "native
    fontification". In fact, such an object has no delimiter either, so it
    would never be a true replacement.

Now, between "srcname" and "source": I'm used to whatever my Yasnippet is
entering for me. That's currently "srcname". I don't have a strong opinion,
though, to choose one over the other, except that I like Nick's argument with
the table analogy.

> I agree on [2] "call".

I clearly agree on "call" as well.

Here, I'd like to ask: what about "sbe"?  In my own understanding, it's a
call, absolutely similar to "call". Is there a technical reason to be forced
to differentiate both?  If no, can we use "call" as well instead of "sbe"?

> I'm confused by [3] so I will say nothing for now, except to ask some
> questions: are we talking about what a human would use to label a piece of
> data for consumption by a block (including perhaps the future possibilities
> of lists and paragraphs that Tom brought up)? what babel would use to label
> a results block (possibly so that it could be consumed by another block in a
> chain)? both? would that mean that #+tblname would go the way of the dodo
> and that tables would be labelled with #+data (or #+object or whatever else
> we come up with)?

For point 3, Eric, I guess that whichever term is chosen, that does not mean
that "results" will change (I mean: when it's a result of a block execution)?

In other words, if we choose for "object", we still will have the possibility
to use "results" (automatically generated) and "object" to refer to something
we want to use in another call?

>>>                 named data [3] -- "tblname" "resname" "results" "data"

I don't specifically like "resname".

I would keep "results" for automatically generated "results".

I do like "data", but can learn to like "object" as a more generic term,
future-proof for coming extensions.

Last remark: we could get one step further and wonder if it wouldn't be good
to impose a single way to pass variables? We currently have two different
mechanisms:

    #+srcname: convert-date-to-French-format
    #+begin_src sql :var column=""
    CONVERT(varchar(10), $column, 103) AS $column
    #+end_src

and

    #+srcname: convert-date-to-French-format(column="")
    #+begin_src sql
    CONVERT(varchar(10), $column, 103) AS $column
    #+end_src

I guess that the first one is easier if we want to construct complex variable
values (which call Emacs Lisp code or such), but...

Thanks for your comments...

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [RFC] Standardized code block keywords

[Sebastien Vauban]

Hi Torsten,

Torsten Wagner wrote:
> I tend to  #+results: because it fits more to the entire babel syntax.
> However, earlier on the mailing list people were pointing out that one
> is going to change "results" for a unknown source block (that was the
> reason "data" was introduced).... and I think this is a valid
> argument. Maybe "data" and "results" should be both valid if only to
> pleasure human thinking. However, if I understood correctly, maybe
> data could be changed to be more some type of constant? That is,
> #+data: foo can not be changed by a source code block named foo
> (because it isn't a "result" but "data") but only by human (as a
> "data" input). Does this make sense?

Yes, #+results are automatically generated by execution of some code.

But, if you want to start with something, not generated, you had to insert
yourself a #+results block until the more logical #+data had been introduced.

I like your explanation about the fact that such a manually-entered block is
"constant".

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 3887 bytes --]

On Fri, Oct 21, 2011 at 10:14 AM, Christian Moe <mail@christianmoe.com>wrote:

> Hi again,
>
> I can quickly think of two advantages of the late lamented (if only by me)
> #+BABEL header over using properties.
>

I also think that keeping the #+BABEL would be a good idea, as it keeps the
options for babel separate (as are the functions - org-babel... ). It is
true that babel is getting more and more interwined with org (which is a
good think), but especially in my case, I use org more or less exclusively
for literate programming (babel) and some org features (archiving, note
capture...) in this context, it would be really nice to be able to keep the
options for babel easily identifyable.

I defined a new drawer (:BABEL:) and put my options / arguments / properties
for babel in there. So my question would be: would i be possible to leave
#+BABEL as an equivalent for #+PROPERTY ? Yes, it could be misused, but also
used to make these options easily identifyable.

My setup at the moment:

#+DRAWERS: HIDDEN PROPERTIES STATE CONFIG BABEL OUTPUT LATEX

:BABEL:
#+BABEL: :session *R*
#+BABEL: :results output
#+BABEL: :exports code
#+BABEL: :comments yes
#+BABEL: :tangle Analysis_sensitivity.R
#+BABEL: :var
RESULTSDIR="/media/Results/clusterResults/nsa/LHCube/nsa.91.up-to-date/results/"
#+BABEL: :var
ANALYSISDIR="/home/rkrug/Documents/Projects/BiocontrolAndAlienDynamics/nonSpatialAcacia/LHCube/nsa.91.up-to-date/analysis/"
:END:



> 1. Allowing you to specify multiple buffer-wide options on the same line
> (keeping things short), in the same colon :syntax as used in a src block
> header (keeping things consistent and easy to copy back and forth). None of
> this makes a substantive difference.
>
> 2. Allowing you to pass multiple buffer-wide arguments with :var. This
> could make a substantive difference in some applications. The following will
> work:
>
>  #+BABEL: :var euro=1.3791 :var salestax=.15
>
> The following will not, since it tries to set the same property:
>
>  #+PROPERTY: var euro=1.3791
>  #+PROPERTY: var salestax=.15
>

I think it is a very important point, that the construct with :var still
works - but as Eric only mentioned the *naming*, I assume that in the actual
usage nothing changes.

OK - the colon at the beginning - but I clud live with that change, although
it makes it clear what the actual argument is which is set.


> If BABEL is dropped for PROPERTY, it would be good for the :var: property
> to support multiple arguments (comma-separated would be good for consistency
> with passing arguments through the SRCNAME). E.g.:
>
>  #+PROPERTY: var euro=1.3791, salestax=.15
>

I think that would be a good idea, but I think that was already discussed
some time ago and rejected?


> I think I'd like this better in any case.
>

No - rather in separate lines... but different strokes for different
folks...

Cheers,

Rainer


> Yours,
> Christian
>
>
>
> On 10/21/11 9:28 AM, Sebastien Vauban wrote:
>
>> Multiple lines may be used to specify multiple properties. e.g.,
>>>
>>> #+PROPERTY: results silent
>>> #+PROPERTY: cache yes
>>>
>>
>> *But* I did not know it was limited to _one property per line_.
>>
>> Knowing that:
>>
>> - there is no confusion at all -- we simply (have to) know that the first
>> word
>>   is the "name" without colon, and the rest are "values"
>>
>> - my argument in favor of #+PROPERTIES (over #+PROPERTY) simply falls.
>>
>> To sum up, I'm perfectly happy with the new choice.
>>
>> Best regards,
>>   Seb
>>
>>
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax (F):       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

[-- Attachment #2: Type: text/html, Size: 5464 bytes --]

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Christian Moe]

On 10/21/11 11:12 AM, Rainer M Krug wrote:
>
>
> On Fri, Oct 21, 2011 at 10:14 AM, Christian Moe <mail@christianmoe.com
> <mailto:mail@christianmoe.com>> wrote:
(...)
>     2. Allowing you to pass multiple buffer-wide arguments with :var.
>     This could make a substantive difference in some applications. The
>     following will work:
>
>       #+BABEL: :var euro=1.3791 :var salestax=.15
>
>     The following will not, since it tries to set the same property:
>
>       #+PROPERTY: var euro=1.3791
>       #+PROPERTY: var salestax=.15
>
>
> I think it is a very important point, that the construct with :var
> still works - but as Eric only mentioned the *naming*, I assume that
> in the actual usage nothing changes.
>

Hi, Rainer,

My point was that there is at least one (minor) case where properties 
are not functionally equivalent to the BABEL line: You cannot pass 
arguments for more than one variable buffer-wide, because you can't 
have multiple var properties at the same time, and at present, one var 
property only sets one variable.

The behavior of properties has not changed. What has changed is the 
removal of the BABEL header, whose colon (:var) syntax did allow you 
to set multiple variables buffer-wide should you wish to.

Yours,
Christian

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 2180 bytes --]

On Fri, Oct 21, 2011 at 12:47 PM, Christian Moe <mail@christianmoe.com>wrote:

> On 10/21/11 11:12 AM, Rainer M Krug wrote:
>
>>
>>
>> On Fri, Oct 21, 2011 at 10:14 AM, Christian Moe <mail@christianmoe.com
>> <mailto:mail@christianmoe.com>**> wrote:
>>
> (...)
>
>     2. Allowing you to pass multiple buffer-wide arguments with :var.
>>    This could make a substantive difference in some applications. The
>>    following will work:
>>
>>      #+BABEL: :var euro=1.3791 :var salestax=.15
>>
>>    The following will not, since it tries to set the same property:
>>
>>      #+PROPERTY: var euro=1.3791
>>      #+PROPERTY: var salestax=.15
>>
>>
>> I think it is a very important point, that the construct with :var
>> still works - but as Eric only mentioned the *naming*, I assume that
>> in the actual usage nothing changes.
>>
>>
> Hi, Rainer,
>
> My point was that there is at least one (minor) case where properties are
> not functionally equivalent to the BABEL line: You cannot pass arguments for
> more than one variable buffer-wide, because you can't have multiple var
> properties at the same time, and at present, one var property only sets one
> variable.
>

So, using your above mentioned example, after the first PROPERTY line,
euro=1.3795 and SALESTAX not set, while after the second one salestax=.15,
and euro is unset? That would be quite bad.


>
> The behavior of properties has not changed. What has changed is the removal
> of the BABEL header, whose colon (:var) syntax did allow you to set multiple
> variables buffer-wide should you wish to.
>

To clarify: before, we could use #+BABEL and #PROPERTY to do similar things.
Now the whole #+BABEL has been removed, and only the functionality from
#+PROPERTY is left - correct?

Rainer



>
> Yours,
> Christian
>
>
>
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax (F):       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

[-- Attachment #2: Type: text/html, Size: 3440 bytes --]

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Christian Moe]

On 10/21/11 12:59 PM, Rainer M Krug wrote:

> So, using your above mentioned example, after the first PROPERTY line,
> euro=1.3795 and SALESTAX not set, while after the second one
> salestax=.15, and euro is unset? That would be quite bad.

That's what I'd expected, but actually, euro is set and salestax is 
not. Apparently subsequent PROPERTY lines are ignored if they try to 
set an already existing property.

> To clarify: before, we could use #+BABEL and #PROPERTY to do similar
> things. Now the whole #+BABEL has been removed, and only the
> functionality from #+PROPERTY is left - correct?

That's my understanding. And #+PROPERTY offers equivalent 
functionality in almost every way, but not, as far as I can 
understand, in this corner case.

Christian

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 1505 bytes --]

On Fri, Oct 21, 2011 at 1:17 PM, Christian Moe <mail@christianmoe.com>wrote:

> On 10/21/11 12:59 PM, Rainer M Krug wrote:
>
>  So, using your above mentioned example, after the first PROPERTY line,
>> euro=1.3795 and SALESTAX not set, while after the second one
>> salestax=.15, and euro is unset? That would be quite bad.
>>
>
> That's what I'd expected, but actually, euro is set and salestax is not.
> Apparently subsequent PROPERTY lines are ignored if they try to set an
> already existing property.
>

That's bad - really bad. Because then I have to substantially change my
files.


>
>  To clarify: before, we could use #+BABEL and #PROPERTY to do similar
>> things. Now the whole #+BABEL has been removed, and only the
>> functionality from #+PROPERTY is left - correct?
>>
>
> That's my understanding. And #+PROPERTY offers equivalent functionality in
> almost every way, but not, as far as I can understand, in this corner case.
>

Then I would suggest to leave #+BABEL until these cases are also implemented
in #+PROPERTY - but I suppose, they are there for a purpose.

Cheers,

Rainer


>
> Christian
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax (F):       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

[-- Attachment #2: Type: text/html, Size: 2681 bytes --]

Re: [RFC] Standardized code block keywords

[Nicolas Goaziou]

Hello,

Eric Schulte <schulte.eric@gmail.com> writes:

> There are currently a number of instances of synonymous keywords when
> dealing with code blocks, specifically.
>
>          named code blocks [1] -- "source" "srcname" "function"
> calling external functions [2] -- "call" "lob"
>                 named data [3] -- "tblname" "resname" "results" "data"
>

- Cases [1] and [2] : I'd suggest to drop all of them and to use "name",
  shared by both source code and data. Is it really different to name
  a source block or a list?

- Case [3] : I like "call". "lob" is too cryptic.

> Are there cases where we want to continue to allow synonyms (e.g., in
> named data so that "results" can be used for code block results but
> "data" can be used for hand-written data)?

No. One Keyword to name them all.

Regards,

[1] DEFINITION NOT FOUND: 1

[2] DEFINITION NOT FOUND: 3

[3] DEFINITION NOT FOUND: 2

-- 
Nicolas Goaziou

Re: [RFC] Standardized code block keywords

[Eric Schulte]

tsd@tsdye.com (Thomas S. Dye) writes:

> Eric Schulte <schulte.eric@gmail.com> writes:
>
>>> [1] I have the same "annoying" feelings with #+SOURCE, #+SRCNAME, #+FUNCTION,
>>> #+CALL, #+LOB, and SBE, some of which are interchangeable; some
>>> not. I'd prefer
>>> deprecating an old form when a better one is found.
>>
>> This point of view has been raised previously both on the mailing list
>> and in the #org-mode IRC chat room.  I think it is time that we decided
>> as a community what we want to do about the prevalence of code block
>> synonyms -- we should make this decision before the release of Emacs24
>> after which syntax will become harder to change.
>>
>> There are currently a number of instances of synonymous keywords when
>> dealing with code blocks, specifically.
>>
>>          named code blocks [1] -- "source" "srcname" "function"
>> calling external functions [2] -- "call" "lob"
>>                 named data [3] -- "tblname" "resname" "results" "data"
>>
>> Ideally if we limit each of the above to only one alternative we could
>> simplify the specification of code blocks in Org-mode making them easier
>> to learn and use and removing some of the mystery around their syntax.
>>
>> What does everyone think?
>>
>> Are there suggestions for the best names for each code block entity
>> (either in the list or not in the list)?
>>
>> Are there cases where we want to continue to allow synonyms (e.g., in
>> named data so that "results" can be used for code block results but
>> "data" can be used for hand-written data)?
>>
>> Thanks -- Eric
>>
>> Footnotes: 
>> [1] named code blocks
>>
>>     #+source: foo
>>     #+begin_src emacs-lisp
>>       'foo
>>     #+end_src
>>
>>     #+srcname: foo
>>     #+begin_src emacs-lisp
>>       'foo
>>     #+end_src
>>
>>     #+function: foo
>>     #+begin_src emacs-lisp
>>       'foo
>>     #+end_src
>>
>> [2]  calling external functions
>>
>>     #+call: foo()
>>
>>     #+lob: foo()
>>
>> [3]  named data
>>
>>     #+data: something
>>     : something
>>     #+results: something
>>     : something
>>
>>     etc...
>
> Hi Eric,
>
> named code blocks [1] "source"
> calling external functions [2] "call"
> named data [3] "object"
>

Noted, thanks, your choices for 1 and 2 are my favorite as well.

>
> My motivation for [3] "object" instead of the suggested alternates is
> the hope that it will be possible to name things like lists and
> paragraphs (that aren't results or data) and pass these objects to
> source code blocks.
>

I would say that I would consider paragraphs and lists to be "data" as
well, but I think object is a fine alternative.  Also, lists are already
a supported data type.

#+data: something
- 1
- 2
- 3

#+begin_src emacs-lisp :var it=something :results list
  (reverse it)
#+end_src

#+results:
- 3
- 2
- 1

Thanks for sharing -- Eric

>
> All the best,
> Tom

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [RFC] Standardized code block keywords

[Eric Schulte]

>
> I disagree with Tom on [1]: it should clearly be "srcname", in analogy
> to #+tblname - and also so I don't have to change my files :-} (but see
> my question about tblname below).
>
> I agree on [2] "call".
>

noted

>
> I'm confused by [3] so I will say nothing for now, except to ask some
> questions: are we talking about what a human would use to label a piece
> of data for consumption by a block (including perhaps the future
> possibilities of lists and paragraphs that Tom brought up)?

Yes, and lists are already supported.  Supporting paragraphs would not
be difficult.

> what babel would use to label a results block (possibly so that it
> could be consumed by another block in a chain)? both?

yes

> would that mean that #+tblname would go the way of the dodo and that
> tables would be labelled with #+data (or #+object or whatever else we
> come up with)?
>

I am hesitant to suggest changing #+tblname: as it is used throughout
the rest of Org-mode, so it may be that whatever choice is made here
tblname will remain a synonymous option.

Thanks -- Eric

>
> Thanks,
> Nick
>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [RFC] Standardized code block keywords

[Eric Schulte]

>> I'm confused by [3] so I will say nothing for now, except to ask some
>> questions: are we talking about what a human would use to label a piece
>> of data for consumption by a block (including perhaps the future
>> possibilities of lists and paragraphs that Tom brought up)? what babel
>> would use to label a results block (possibly so that it could be
>> consumed by another block in a chain)? both? would that mean
>> that #+tblname would go the way of the dodo and that tables would be
>> labelled with #+data (or #+object or whatever else we come up with)?
>
> +1 (Confused, too)
>

well, I guess it is good that this discussion has begun if only to clear
up this lingering uncertainty.

>
> I wasn't even aware of #+DATA. Does it do anything TBLNAME and SRCNAME
> don't?
>

from the prospective of code blocks it is exactly synonymous with
tblname.  Srcname is different in that it labels code blocks.

>
> A reason to keep TBLNAME is that it's also used by the spreadsheet
> remote references. If Babel looked for DATA instead, a table that is
> both a remote reference for another spreadsheet and a data source for
> a src block would need both TBLNAME and DATA, which seems redundant.
>

agreed, I'm thinking that tblname will at least remain an option no
matter what decision is made.

>
> As for labeling lists and paragraphs, I recall from the list that
> Nicolas Goaziou is working on a generalized way to set captions,
> labels and attributes for various kinds of Org block, as is possible
> now for tables and images. I thought that sounded promising. I don't
> know if he planned for block names, too (currently we have tblname but
> no imgname), but that could make sense. In which case it might be a
> good idea to coordinate.
>

Agreed, I was not aware of this work.  Thanks for sharing.  In this vein
I would like to voice my desire to be able to add captions to code
blocks, the lack of this feature has bitten me in the past.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [RFC] Standardized code block keywords

[Eric Schulte]

>
> Now, between "srcname" and "source": I'm used to whatever my Yasnippet is
> entering for me. That's currently "srcname". I don't have a strong opinion,
> though, to choose one over the other, except that I like Nick's argument with
> the table analogy.
>
>> I agree on [2] "call".
>
> I clearly agree on "call" as well.
>

noted, thanks

>
> Here, I'd like to ask: what about "sbe"?  In my own understanding, it's a
> call, absolutely similar to "call". Is there a technical reason to be forced
> to differentiate both?  If no, can we use "call" as well instead of "sbe"?
>

The only difference is that sbe is a function name, and to name a
function call (a function which will take up that term in the entire
Emacs-lisp namespace across all applications) seems somewhat pushy.

>
>> I'm confused by [3] so I will say nothing for now, except to ask some
>> questions: are we talking about what a human would use to label a piece of
>> data for consumption by a block (including perhaps the future possibilities
>> of lists and paragraphs that Tom brought up)? what babel would use to label
>> a results block (possibly so that it could be consumed by another block in a
>> chain)? both? would that mean that #+tblname would go the way of the dodo
>> and that tables would be labelled with #+data (or #+object or whatever else
>> we come up with)?
>
> For point 3, Eric, I guess that whichever term is chosen, that does not mean
> that "results" will change (I mean: when it's a result of a block execution)?
>

I would be happy for results to change to data or tblname (if a table)
or whatever else is selected.

>
> In other words, if we choose for "object", we still will have the possibility
> to use "results" (automatically generated) and "object" to refer to something
> we want to use in another call?
>
>>>>                 named data [3] -- "tblname" "resname" "results" "data"
>
> I don't specifically like "resname".
>
> I would keep "results" for automatically generated "results".
>
> I do like "data", but can learn to like "object" as a more generic term,
> future-proof for coming extensions.
>

I'll mark you down as undecided for this term. :)

>
> Last remark: we could get one step further and wonder if it wouldn't be good
> to impose a single way to pass variables? We currently have two different
> mechanisms:
>
>     #+srcname: convert-date-to-French-format
>     #+begin_src sql :var column=""
>     CONVERT(varchar(10), $column, 103) AS $column
>     #+end_src
>
> and
>
>     #+srcname: convert-date-to-French-format(column="")
>     #+begin_src sql
>     CONVERT(varchar(10), $column, 103) AS $column
>     #+end_src
>
> I guess that the first one is easier if we want to construct complex variable
> values (which call Emacs Lisp code or such), but...
>

I don't feel that this example causes as much confusion, but if I'm
wrong I am open to change on this front.  Although the only possible
change here would be to remove the second option as the first method of
specifying variables is central to code block management.

>
> Thanks for your comments...
>

Thanks for your feedback, Best -- Eric

>
> Best regards,
>   Seb

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [RFC] Standardized code block keywords

[Eric Schulte]

> Just to make it as easy as possible for everyone....
> Might it be possible to introduce a small flags like "obsolete" and
> "stable" (standard)
> Old functions, old syntax, etc., might move first to obsolete before
> completely removed...
> We could open an older file and if it isn't working, we could try
>
> #+PROPERTY: babel-function-set obsolete
>

I think that making use of such a feature is almost as onerous as
changing to the new terms (which is a simple search replace, in fact
once terms are selected I'll happily share a function on list which can
be used to convert all old terms in existing Org-mode files).

>
> if it works, we have to modify the code, because obviously the code
> requires changed to be compatible in the future. However, just for the
> moment it is still working. This would give people more time to change
> there code accordingly. As murphy law tells us one will notice that
> the particular file is broken exact 5 minutes before the meeting with
> your boss standing behind you yelling.... print it, print it  ;)
>
> I know git would be perfect to keep the code base frozen for a certain
> syntax. However, babel is bundled with org-mode which is bundled with
> Emacs. Thus, it might be very difficult to tell people they have to
> use org-babel from git with the tag [org-babel_XX] if they want to use
> there old style files.  AFAIK org-babel does not even come with a own
> version numbering, right?
>
> Alternatively, keep the syntax a little bit longer as it is and create
> warning messages to point users to future changes (not sure how much
> time left for emacs24)
> "Warning: #+lob: in line XX is obsolete, please use #+call: in the
> future. (manual-link)"
>
> To make is short, is is possible to introduce changes "slowly"
>

I fear this would simply serve to introduce more complexity and
confusion.


>
> As for voting:
> [1]
> #+function: would be what I would expect from other programming
> languages. Where an unnamed source code block would be something like
> a lambda function.
> However, "function" as a term is heavily used in many target languages
> too. This makes parsing, reading and discussing a bit difficult. ("I
> called the function foo", "Wait, do you call the org-mode function
> foo, or the python function foo?")
> Thus, I vote for #+srcname similar to #+tblname to make sure about the
> difference between org-babel and the target languages.
>
> [2]
> #+call:, simply because I never can remember "lob" and the acronym is
> something difficult for newbies.
>

noted, thanks

>
> [3]
> I tend to  #+results: because it fits more to the entire babel syntax.
> However, earlier on the mailing list people were pointing out that one
> is going to change "results" for a unknown source block (that was the
> reason "data" was introduced).... and I think this is a valid
> argument. Maybe "data" and "results" should be both valid if only to
> pleasure human thinking. However, if I understood correctly, maybe
> data could be changed to be more some type of constant? That is,
> #+data: foo can not be changed by a source code block named foo
> (because it isn't a "result" but "data") but only by human (as a
> "data" input). Does this make sense?
>

yes, I'll mark you down for "data and results", which I think is a
perfectly fine option.

Thanks for sharing -- Eric

>
> Totti
>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [RFC] Standardized code block keywords

[Eric Schulte]

"Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:

> Hi Torsten,
>
> Torsten Wagner wrote:
>> I tend to  #+results: because it fits more to the entire babel syntax.
>> However, earlier on the mailing list people were pointing out that one
>> is going to change "results" for a unknown source block (that was the
>> reason "data" was introduced).... and I think this is a valid
>> argument. Maybe "data" and "results" should be both valid if only to
>> pleasure human thinking. However, if I understood correctly, maybe
>> data could be changed to be more some type of constant? That is,
>> #+data: foo can not be changed by a source code block named foo
>> (because it isn't a "result" but "data") but only by human (as a
>> "data" input). Does this make sense?
>
> Yes, #+results are automatically generated by execution of some code.
>
> But, if you want to start with something, not generated, you had to insert
> yourself a #+results block until the more logical #+data had been introduced.
>
> I like your explanation about the fact that such a manually-entered block is
> "constant".
>

I like "constant" too, but the goals is to remove synonyms, not add
them. :)

Thanks -- Eric

>
> Best regards,
>   Seb

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [RFC] Standardized code block keywords

[Eric Schulte]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> Eric Schulte <schulte.eric@gmail.com> writes:
>
>> There are currently a number of instances of synonymous keywords when
>> dealing with code blocks, specifically.
>>
>>          named code blocks [1] -- "source" "srcname" "function"
>> calling external functions [2] -- "call" "lob"
>>                 named data [3] -- "tblname" "resname" "results" "data"
>>
>
> - Cases [1] and [2] : I'd suggest to drop all of them and to use "name",
>   shared by both source code and data. Is it really different to name
>   a source block or a list?
>

I think you mean [1] and [3] in the above, and I agree, these could
easily be the same term and "name" has a nice generality to it.
Although it is unintuitive in the case of un-named data, e.g.,

#+name:
| 1 |
| 2 |
| 3 |

looks weird to me.

>
> - Case [3] : I like "call". "lob" is too cryptic.
>

assuming you mean [2] above, I think call is emerging as the clear
winner in this case.

>
>> Are there cases where we want to continue to allow synonyms (e.g., in
>> named data so that "results" can be used for code block results but
>> "data" can be used for hand-written data)?
>
> No. One Keyword to name them all.
>

Noted, Thanks for the input -- Eric

>
> Regards,
>
> [1] DEFINITION NOT FOUND: 1
>
> [2] DEFINITION NOT FOUND: 3
>
> [3] DEFINITION NOT FOUND: 2

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Eric Schulte]

Christian Moe <mail@christianmoe.com> writes:

> Hi again,
>
> I can quickly think of two advantages of the late lamented (if only by 
> me) #+BABEL header over using properties.
>
> 1. Allowing you to specify multiple buffer-wide options on the same 
> line (keeping things short), in the same colon :syntax as used in a 
> src block header (keeping things consistent and easy to copy back and 
> forth). None of this makes a substantive difference.
>

Understood, the new method will require multiple lines.  Everything is a
trade-off...

>
> 2. Allowing you to pass multiple buffer-wide arguments with :var. This
> could make a substantive difference in some applications. The 
> following will work:
>
>    #+BABEL: :var euro=1.3791 :var salestax=.15
>
> The following will not, since it tries to set the same property:
>
>    #+PROPERTY: var euro=1.3791
>    #+PROPERTY: var salestax=.15
>
> If BABEL is dropped for PROPERTY, it would be good for the :var: 
> property to support multiple arguments (comma-separated would be good 
> for consistency with passing arguments through the SRCNAME). E.g.:
>
>    #+PROPERTY: var euro=1.3791, salestax=.15
>
> I think I'd like this better in any case.
>

Nice idea.  This same issue with "var" arose when we first started
allowing header arguments to be specified inside subtree properties.
I've just implemented your suggestion so the following are now possible.

#+PROPERTY: var foo=1, bar=2
#+PROPERTY: cache yes

#+begin_src emacs-lisp
  (+ foo bar)
#+end_src

#+results[be32e67491d4e92f75769aebe423c20ca01626fe]:
: 3

and

#+begin_src emacs-lisp :var foo="this", bar="that"
  (concat foo " " bar)
#+end_src

#+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]:
: this that

Thanks for the suggestion and I hope the above is a sufficient
replacement for the now-missing #+BABEL: syntax.

Cheers -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [RFC] Standardized code block keywords

[Sebastien Vauban]

Hi Eric,

Eric Schulte wrote:
>> Now, between "srcname" and "source": I'm used to whatever my Yasnippet is
>> entering for me. That's currently "srcname". I don't have a strong opinion,
>> though, to choose one over the other, except that I like Nick's argument with
>> the table analogy.
>>
>>> I agree on [2] "call".
>>
>> I clearly agree on "call" as well.
>
> noted, thanks

I think you'll get unanimity on that one.

>> Here, I'd like to ask: what about "sbe"?  In my own understanding, it's a
>> call, absolutely similar to "call". Is there a technical reason to be forced
>> to differentiate both?  If no, can we use "call" as well instead of "sbe"?
>
> The only difference is that sbe is a function name, and to name a
> function call (a function which will take up that term in the entire
> Emacs-lisp namespace across all applications) seems somewhat pushy.

OK. Point understood. May I suggest to try to find a better name, still?  Once
we're at it, modifying one extra line in the documentation won't hurt.

I don't know what others find, but I've never understood what it meant. OK,
now (since yesterday, in fact), I know it means "source block evaluation", but
that's not really intuitive.

I'd opt for "ob-call" (package name + "call") or something like that, if I
could choose.

>>> I'm confused by [3] so I will say nothing for now, except to ask some
>>> questions: are we talking about what a human would use to label a piece of
>>> data for consumption by a block (including perhaps the future possibilities
>>> of lists and paragraphs that Tom brought up)? what babel would use to label
>>> a results block (possibly so that it could be consumed by another block in a
>>> chain)? both? would that mean that #+tblname would go the way of the dodo
>>> and that tables would be labelled with #+data (or #+object or whatever else
>>> we come up with)?
>>
>> For point 3, Eric, I guess that whichever term is chosen, that does not mean
>> that "results" will change (I mean: when it's a result of a block execution)?

I was expecting you'd always keep "results" for auto-inserted results (after a
code block evaluation). But it makes sense to prefer the one term that will
win.

> I would be happy for results to change to data or tblname (if a table)
> or whatever else is selected.

OK, clear.

>> In other words, if we choose for "object", we still will have the possibility
>> to use "results" (automatically generated) and "object" to refer to something
>> we want to use in another call?
>>
>>>>>                 named data [3] -- "tblname" "resname" "results" "data"
>>
>> I don't specifically like "resname".
>>
>> I would keep "results" for automatically generated "results".
>>
>> I do like "data", but can learn to like "object" as a more generic term,
>> future-proof for coming extensions.
>
> I'll mark you down as undecided for this term. :)

Yep!  I'm open to any suggestion you'll make.

>> Last remark: we could get one step further and wonder if it wouldn't be good
>> to impose a single way to pass variables? We currently have two different
>> mechanisms:
>>
>>     #+srcname: convert-date-to-French-format
>>     #+begin_src sql :var column=""
>>     CONVERT(varchar(10), $column, 103) AS $column
>>     #+end_src
>>
>> and
>>
>>     #+srcname: convert-date-to-French-format(column="")
>>     #+begin_src sql
>>     CONVERT(varchar(10), $column, 103) AS $column
>>     #+end_src
>>
>> I guess that the first one is easier if we want to construct complex variable
>> values (which call Emacs Lisp code or such), but...
>
> I don't feel that this example causes as much confusion, but if I'm
> wrong I am open to change on this front.  Although the only possible
> change here would be to remove the second option as the first method of
> specifying variables is central to code block management.

Just that I remember both syntaxes weren't handled the same way for error
reporting (remember, when there is no default value: in one case, you can get
the name of the faulty block; in the other, not), and that makes me think is
not as simple as an alias. Hence, your Babel code is or can become different
just because there are different alternatives to write certain things down.

Then, as a user, I always wonder what's the best one?  "For a good error
reporting (with the name of the code block being outputted), which one do I
have to use?" and such questions...

If we only have one way, we can be sure everybody experiences the same things
with the same semantical input.

Another point, that may or may not have much to do with this, is that I don't
have anymore the source name exported in HTML -- dunno when it disappeared,
though. I remember that, at some point, it was due to having, or not, a
default value (at the time, having no default value was still allowed), but
now, even with the default values for every var, I miss those names in the
HTML (for literate programming support, it is quite useful to be able to see
the name of the block along with the code).

I repeat myself, but thanks, once again, for tackling this naming "problem".

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [RFC] Standardized code block keywords

[Sebastien Vauban]

Hi Eric and Torsten,

Eric Schulte wrote:
>> We could open an older file and if it isn't working, we could try
>>
>> #+PROPERTY: babel-function-set obsolete
>
> I think that making use of such a feature is almost as onerous as
> changing to the new terms (which is a simple search replace, in fact
> once terms are selected I'll happily share a function on list which can
> be used to convert all old terms in existing Org-mode files).

I also think, for the sake of the efficiency we're trying to achieve, that we
must forget about the past in one "big bang" (v7.8 or whatever). Supporting it
temporarily in v7.8 and not anymore in 7.9 won't really help, IMHO.

Of course, it must be clearly stated that this change will break every old
report. That must be the first visible item of the description of 7.8.

Regarding a function to automate the changes, this is what I used this
afternoon (quite dumb, certainly to be improved):

#+begin_src emacs-lisp
(defun my/org-propertyze-babel-line ()
  (interactive)
  (search-forward-regexp ":")
  (delete-backward-char 2)
  (insert "\n#+PROPERTY:  "))
#+end_src

Put point after `#+BABEL:' and apply it as many times as needed.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [RFC] Standardized code block keywords

[Eric Schulte]

So far I have the following.

code block names
| source  | dye     |
| srcname | dokos   |
| srcname | moe     |
| srcname | vauban  |
| srcname | wagner  |
| name    | goaziou |

call lines
| call | dye     |
| call | dokos   |
| call | moe     |
| call | vauban  |
| call | wagner  |
| call | goaziou |

data names
| object         | dye     |
| (data results) | wagner  |
| name           | goaziou |

It seems that srcname is pulling ahead for naming code blocks (to my
surprise) and that call is the clear winner for call lines.  labeling
data is certainly less obvious and has tricky entanglements with other
parts of Org-mode (e.g., tables will likely continue to be named with
tblname).

I'll likely be out of contact for the remainder of the weekend but when
I'm back I'll update tallies and we can see where the consensus stands.
Thanks to everyone who has or will reply, I think the best way to find
the most natural options for these decisions is through surveys and it
is great to have a community so willing to help.

Cheers -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [RFC] Standardized code block keywords

[Thomas S. Dye]

Eric Schulte <schulte.eric@gmail.com> writes:

> tsd@tsdye.com (Thomas S. Dye) writes:
>
>> Eric Schulte <schulte.eric@gmail.com> writes:
>>
>>>> [1] I have the same "annoying" feelings with #+SOURCE, #+SRCNAME, #+FUNCTION,
>>>> #+CALL, #+LOB, and SBE, some of which are interchangeable; some
>>>> not. I'd prefer
>>>> deprecating an old form when a better one is found.
>>>
>>> This point of view has been raised previously both on the mailing list
>>> and in the #org-mode IRC chat room.  I think it is time that we decided
>>> as a community what we want to do about the prevalence of code block
>>> synonyms -- we should make this decision before the release of Emacs24
>>> after which syntax will become harder to change.
>>>
>>> There are currently a number of instances of synonymous keywords when
>>> dealing with code blocks, specifically.
>>>
>>>          named code blocks [1] -- "source" "srcname" "function"
>>> calling external functions [2] -- "call" "lob"
>>>                 named data [3] -- "tblname" "resname" "results" "data"
>>>
>>> Ideally if we limit each of the above to only one alternative we could
>>> simplify the specification of code blocks in Org-mode making them easier
>>> to learn and use and removing some of the mystery around their syntax.
>>>
>>> What does everyone think?
>>>
>>> Are there suggestions for the best names for each code block entity
>>> (either in the list or not in the list)?
>>>
>>> Are there cases where we want to continue to allow synonyms (e.g., in
>>> named data so that "results" can be used for code block results but
>>> "data" can be used for hand-written data)?
>>>
>>> Thanks -- Eric
>>>
>>> Footnotes: 
>>> [1] named code blocks
>>>
>>>     #+source: foo
>>>     #+begin_src emacs-lisp
>>>       'foo
>>>     #+end_src
>>>
>>>     #+srcname: foo
>>>     #+begin_src emacs-lisp
>>>       'foo
>>>     #+end_src
>>>
>>>     #+function: foo
>>>     #+begin_src emacs-lisp
>>>       'foo
>>>     #+end_src
>>>
>>> [2]  calling external functions
>>>
>>>     #+call: foo()
>>>
>>>     #+lob: foo()
>>>
>>> [3]  named data
>>>
>>>     #+data: something
>>>     : something
>>>     #+results: something
>>>     : something
>>>
>>>     etc...
>>
>> Hi Eric,
>>
>> named code blocks [1] "source"
>> calling external functions [2] "call"
>> named data [3] "object"
>>
>
> Noted, thanks, your choices for 1 and 2 are my favorite as well.
>
>>
>> My motivation for [3] "object" instead of the suggested alternates is
>> the hope that it will be possible to name things like lists and
>> paragraphs (that aren't results or data) and pass these objects to
>> source code blocks.
>>
>
> I would say that I would consider paragraphs and lists to be "data" as
> well, but I think object is a fine alternative.  Also, lists are already
> a supported data type.
>
> #+data: something
> - 1
> - 2
> - 3
>
> #+begin_src emacs-lisp :var it=something :results list
>   (reverse it)
> #+end_src
>
> #+results:
> - 3
> - 2
> - 1
>
> Thanks for sharing -- Eric
>
>>
>> All the best,
>> Tom

Hi Eric,

Let me help revise the documentation when the dust settles and the
syntax changes are in place.  As it stands now, #+data: doesn't show up
in the index to the manual, and the entry for #+tblname: leads only to
a description of its use in spreadsheets.

I should have known lists are already supported.  Great work!

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Nick Dokos]

Eric Schulte <schulte.eric@gmail.com> wrote:

> >
> > 2. Allowing you to pass multiple buffer-wide arguments with :var. This
> > could make a substantive difference in some applications. The 
> > following will work:
> >
> >    #+BABEL: :var euro=1.3791 :var salestax=.15
> >
> > The following will not, since it tries to set the same property:
> >
> >    #+PROPERTY: var euro=1.3791
> >    #+PROPERTY: var salestax=.15
> >
> > If BABEL is dropped for PROPERTY, it would be good for the :var: 
> > property to support multiple arguments (comma-separated would be good 
> > for consistency with passing arguments through the SRCNAME). E.g.:
> >
> >    #+PROPERTY: var euro=1.3791, salestax=.15
> >
> > I think I'd like this better in any case.
> >
> 
> Nice idea.  This same issue with "var" arose when we first started
> allowing header arguments to be specified inside subtree properties.
> I've just implemented your suggestion so the following are now possible.
> 
> #+PROPERTY: var foo=1, bar=2
> #+PROPERTY: cache yes
> #+begin_src emacs-lisp
>   (+ foo bar)
> #+end_src
> 
> #+results[be32e67491d4e92f75769aebe423c20ca01626fe]:
> : 3
> 
> and
> 
> #+begin_src emacs-lisp :var foo="this", bar="that"
>   (concat foo " " bar)
> #+end_src
> 
> #+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]:
> : this that
> 
> Thanks for the suggestion and I hope the above is a sufficient
> replacement for the now-missing #+BABEL: syntax.
> 

Just to clarify my understanding: on a #+PROPERTY line, you *have* to
say

#+PROPERTY: var a=1, b=2

but in the code block itself, you can say *either*

#+begin_src emacs-lisp :var a=1, b=2
...


*or*

#+begin_src emacs-lisp :var a=1 :var b=2
...

Experimentally, both of these currently work: do you have any plans to
outlaw the last form?

Also, how does the comma-separated list of variable assignments interact
with a language where comma has syntactic significance? I was primarily
thinking of python where e.g. a=[1,2,3] or a=(1,2) is a legal
construct. AFAICT, that never worked in babel[fn:1], so it may not
matter much, but it may be a good idea to come up with a quoting
mechanism so things like that can be added in the future if necessary.

Thanks,
Nick

Footnotes:

[fn:1] I checked in 7.7 to avoid the recent churn with the following
code block


#+begin_src python :var a='(1,2)'
len(a)
#+end_src

and I get 

,----
|   File "<stdin>", line 3
|     a=[1, [\,, 2]]
|                  ^
| SyntaxError: unexpected character after line continuation character
`----

in the org babel error output buffer.

Re: [RFC] Standardized code block keywords

[Thorsten]

Hi Eric,

Eric Schulte <schulte.eric@gmail.com> writes:

>          named code blocks [1] -- "source" "srcname" "function"
> calling external functions [2] -- "call" "lob"
>                 named data [3] -- "tblname" "resname" "results" "data"

here my votes:

[1] -- "srcname"
[2] -- "call" 
[3] -- ? "
I would choose either "tblname" or "data", but I do not oversee all the
implications. 

Cheers
-- 
Thorsten

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 2597 bytes --]

On Fri, Oct 21, 2011 at 7:37 PM, Eric Schulte <schulte.eric@gmail.com>wrote:

> Christian Moe <mail@christianmoe.com> writes:
>
> > Hi again,
> >
> > I can quickly think of two advantages of the late lamented (if only by
> > me) #+BABEL header over using properties.
> >
> > 1. Allowing you to specify multiple buffer-wide options on the same
> > line (keeping things short), in the same colon :syntax as used in a
> > src block header (keeping things consistent and easy to copy back and
> > forth). None of this makes a substantive difference.
> >
>
> Understood, the new method will require multiple lines.  Everything is a
> trade-off...
>
> >
> > 2. Allowing you to pass multiple buffer-wide arguments with :var. This
> > could make a substantive difference in some applications. The
> > following will work:
> >
> >    #+BABEL: :var euro=1.3791 :var salestax=.15
> >
> > The following will not, since it tries to set the same property:
> >
> >    #+PROPERTY: var euro=1.3791
> >    #+PROPERTY: var salestax=.15
> >
> > If BABEL is dropped for PROPERTY, it would be good for the :var:
> > property to support multiple arguments (comma-separated would be good
> > for consistency with passing arguments through the SRCNAME). E.g.:
> >
> >    #+PROPERTY: var euro=1.3791, salestax=.15
> >
> > I think I'd like this better in any case.
> >
>
> Nice idea.  This same issue with "var" arose when we first started
> allowing header arguments to be specified inside subtree properties.
> I've just implemented your suggestion so the following are now possible.
>
> #+PROPERTY: var foo=1, bar=2
> #+PROPERTY: cache yes
>
> #+begin_src emacs-lisp
>  (+ foo bar)
> #+end_src
>
> #+results[be32e67491d4e92f75769aebe423c20ca01626fe]:
> : 3
>
>
Will

#+PROPERTY: var foo=1
#+PROPERTY: var bar=2

also work, or result in one variable not signed?

Rainer



> and
>
> #+begin_src emacs-lisp :var foo="this", bar="that"
>  (concat foo " " bar)
> #+end_src
>
> #+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]:
> : this that
>
> Thanks for the suggestion and I hope the above is a sufficient
> replacement for the now-missing #+BABEL: syntax.
>
> Cheers -- Eric
>
> --
> Eric Schulte
> http://cs.unm.edu/~eschulte/
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax (F):       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

[-- Attachment #2: Type: text/html, Size: 3707 bytes --]

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 3849 bytes --]

On Fri, Oct 21, 2011 at 8:35 PM, Rainer M Krug <r.m.krug@gmail.com> wrote:

>
>
> On Fri, Oct 21, 2011 at 7:37 PM, Eric Schulte <schulte.eric@gmail.com>wrote:
>
>> Christian Moe <mail@christianmoe.com> writes:
>>
>> > Hi again,
>> >
>> > I can quickly think of two advantages of the late lamented (if only by
>> > me) #+BABEL header over using properties.
>> >
>> > 1. Allowing you to specify multiple buffer-wide options on the same
>> > line (keeping things short), in the same colon :syntax as used in a
>> > src block header (keeping things consistent and easy to copy back and
>> > forth). None of this makes a substantive difference.
>> >
>>
>> Understood, the new method will require multiple lines.  Everything is a
>> trade-off...
>>
>> >
>> > 2. Allowing you to pass multiple buffer-wide arguments with :var. This
>> > could make a substantive difference in some applications. The
>> > following will work:
>> >
>> >    #+BABEL: :var euro=1.3791 :var salestax=.15
>> >
>> > The following will not, since it tries to set the same property:
>> >
>> >    #+PROPERTY: var euro=1.3791
>> >    #+PROPERTY: var salestax=.15
>> >
>> > If BABEL is dropped for PROPERTY, it would be good for the :var:
>> > property to support multiple arguments (comma-separated would be good
>> > for consistency with passing arguments through the SRCNAME). E.g.:
>> >
>> >    #+PROPERTY: var euro=1.3791, salestax=.15
>> >
>> > I think I'd like this better in any case.
>> >
>>
>> Nice idea.  This same issue with "var" arose when we first started
>> allowing header arguments to be specified inside subtree properties.
>> I've just implemented your suggestion so the following are now possible.
>>
>> #+PROPERTY: var foo=1, bar=2
>> #+PROPERTY: cache yes
>>
>> #+begin_src emacs-lisp
>>  (+ foo bar)
>> #+end_src
>>
>> #+results[be32e67491d4e92f75769aebe423c20ca01626fe]:
>> : 3
>>
>>
> Will
>
> #+PROPERTY: var foo=1
> #+PROPERTY: var bar=2
>
> also work, or result in one variable not signed?
>
> Rainer
>

Just to add to it: at the moment I have e.g:

#+BABEL: :var MAINVERSION=0
#+BABEL: :var SVNVERSION=(vc-working-revision (buffer-file-name))
#+BABEL: :var SVNSTATE=( symbol-name (vc-state (or (buffer-file-name)
org-current-export-file)))
#+BABEL: :var SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name)
org-current-export-file)) 'up-to-date) 0 13)
#+BABEL: :var DISP_PACKAGE="seedDisp_0.4-13.tar.gz"

which would look horrible in one line and a nightmare to edit.

Any suggestions how this cold be changed?

In addition: I would like to have a warning if #+BABEL is present in the org
file, so that one remembers that it has to be changed.

Cheers,

Rainer


>
>
>> and
>>
>> #+begin_src emacs-lisp :var foo="this", bar="that"
>>  (concat foo " " bar)
>> #+end_src
>>
>> #+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]:
>> : this that
>>
>> Thanks for the suggestion and I hope the above is a sufficient
>> replacement for the now-missing #+BABEL: syntax.
>>
>> Cheers -- Eric
>>
>> --
>> Eric Schulte
>> http://cs.unm.edu/~eschulte/
>>
>>
>
>
> --
> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
> UCT), Dipl. Phys. (Germany)
>
> Centre of Excellence for Invasion Biology
> Stellenbosch University
> South Africa
>
> Tel :       +33 - (0)9 53 10 27 44
> Cell:       +33 - (0)6 85 62 59 98
> Fax (F):       +33 - (0)9 58 10 27 44
>
> Fax (D):    +49 - (0)3 21 21 25 22 44
>
> email:      Rainer@krugs.de
>
> Skype:      RMkrug
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax (F):       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

[-- Attachment #2: Type: text/html, Size: 6027 bytes --]

Re: [RFC] Standardized code block keywords

[Thomas S. Dye]

Eric Schulte <schulte.eric@gmail.com> writes:

>>> I'm confused by [3] so I will say nothing for now, except to ask some
>>> questions: are we talking about what a human would use to label a piece
>>> of data for consumption by a block (including perhaps the future
>>> possibilities of lists and paragraphs that Tom brought up)? what babel
>>> would use to label a results block (possibly so that it could be
>>> consumed by another block in a chain)? both? would that mean
>>> that #+tblname would go the way of the dodo and that tables would be
>>> labelled with #+data (or #+object or whatever else we come up with)?
>>
>> +1 (Confused, too)
>>
>
> well, I guess it is good that this discussion has begun if only to clear
> up this lingering uncertainty.
>
>>
>> I wasn't even aware of #+DATA. Does it do anything TBLNAME and SRCNAME
>> don't?
>>
>
> from the prospective of code blocks it is exactly synonymous with
> tblname.  Srcname is different in that it labels code blocks.
>
>>
>> A reason to keep TBLNAME is that it's also used by the spreadsheet
>> remote references. If Babel looked for DATA instead, a table that is
>> both a remote reference for another spreadsheet and a data source for
>> a src block would need both TBLNAME and DATA, which seems redundant.
>>
>
> agreed, I'm thinking that tblname will at least remain an option no
> matter what decision is made.
>
>>
>> As for labeling lists and paragraphs, I recall from the list that
>> Nicolas Goaziou is working on a generalized way to set captions,
>> labels and attributes for various kinds of Org block, as is possible
>> now for tables and images. I thought that sounded promising. I don't
>> know if he planned for block names, too (currently we have tblname but
>> no imgname), but that could make sense. In which case it might be a
>> good idea to coordinate.
>>
>
> Agreed, I was not aware of this work.  Thanks for sharing.  In this vein
> I would like to voice my desire to be able to add captions to code
> blocks, the lack of this feature has bitten me in the past.

Hi Eric,

For LaTeX export, the listings package has support for code block
captions.

hth,
Tom
-- 
Thomas S. Dye
http://www.tsdye.com

Re: [RFC] Standardized code block keywords

[Viktor Rosenfeld]

Hi Eric,

my preferences are:

- source for code blocks. I think srcname looks ugly (although not as
  ugly as tblname).
- call
- data and results for, well, data and results. With the same semantics
  as Torsten Wagner suggested, i.e. a source block cannot change the
  contents of a data block. It should create a new result block. Data
  should take precedence over result, i.e. only use result blocks for
  input if there is no data block with the name.

Personally, I don't care for tblname and would happilly replace it with
data.

Cheers,
Viktor

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Christian Moe]

Hi,

Yes, that works nicely, and should solve Rainer's problem.
I haven't been able to think of anything else that can't be handled by 
properties.

And I do think it's a good idea to winnow down the syntax a bit, even 
if things break. I just like to grumble.
:-)

Yours,
Christian

On 10/21/11 7:37 PM, Eric Schulte wrote:
> Nice idea.  This same issue with "var" arose when we first started
> allowing header arguments to be specified inside subtree properties.
> I've just implemented your suggestion so the following are now possible.
>
> #+PROPERTY: var foo=1, bar=2
> #+PROPERTY: cache yes
>
> #+begin_src emacs-lisp
>    (+ foo bar)
> #+end_src
>
> #+results[be32e67491d4e92f75769aebe423c20ca01626fe]:
> : 3
>
> and
>
> #+begin_src emacs-lisp :var foo="this", bar="that"
>    (concat foo " " bar)
> #+end_src
>
> #+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]:
> : this that
>
> Thanks for the suggestion and I hope the above is a sufficient
> replacement for the now-missing #+BABEL: syntax.
>
> Cheers -- Eric

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Darlan Cavalcante Moreira]

It's excellent that now babel understands multiple values in the "var"
property (I was one of the people that wanted this), but "There Is One More
Thing".

Would it be feasible to inherit variables from parent sub-trees?
Effectively, I'd like to append new values in lower level sub-trees, but
AFAIK setting the var property in a sub-tree will still replace the value
set in the parent sub-tree.

That is, in the example below the level-2 sub-trees would not have the foo
variable passed to babel.
--8<---------------cut here---------------start------------->8---
* Code with foo
  :PROPERTIES:
  :var:      foo=1
  :END:

** Code only with bar
   :PROPERTIES:
   :var:      bar=2
   :END:
   src_block
** Code only with baz
   :PROPERTIES:
   :var:      baz=3
   :END:
   src_block
--8<---------------cut here---------------end--------------->8---

Maybe a special keyword, such as "inherit" (or "append") could be used to
incorporate variables defined in the parent sub-tree, such that the example
would become
--8<---------------cut here---------------start------------->8---
* Code with foo
  :PROPERTIES:
  :var:      foo=1
  :END:

** Code with foo and bar
   :PROPERTIES:
   :var:      bar=2, inherit
   :END:
   src_block
** Code with foo and baz
   :PROPERTIES:
   :var:      baz=3, inherit
   :END:
   src_block
--8<---------------cut here---------------end--------------->8---

This should not affect global variables and "inherit" would inherit
variables defined only in the parent sub-tree (unless it also contains the
inherit keyword).

As a use case scenario, suppose I need to perform simulations for a few
different scenarios, each with small variations. This would allow me to
define common variables for a scenario in a higher level sub-tree and more
specific variables in the lower level sub-trees.

--
Darlan Cavalcante


At Fri, 21 Oct 2011 22:24:25 +0200,
Christian Moe <mail@christianmoe.com> wrote:
> 
> Hi,
> 
> Yes, that works nicely, and should solve Rainer's problem.
> I haven't been able to think of anything else that can't be handled by 
> properties.
> 
> And I do think it's a good idea to winnow down the syntax a bit, even 
> if things break. I just like to grumble.
> :-)
> 
> Yours,
> Christian
> 
> On 10/21/11 7:37 PM, Eric Schulte wrote:
> > Nice idea.  This same issue with "var" arose when we first started
> > allowing header arguments to be specified inside subtree properties.
> > I've just implemented your suggestion so the following are now possible.
> >
> > #+PROPERTY: var foo=1, bar=2
> > #+PROPERTY: cache yes
> >
> > #+begin_src emacs-lisp
> >    (+ foo bar)
> > #+end_src
> >
> > #+results[be32e67491d4e92f75769aebe423c20ca01626fe]:
> > : 3
> >
> > and
> >
> > #+begin_src emacs-lisp :var foo="this", bar="that"
> >    (concat foo " " bar)
> > #+end_src
> >
> > #+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]:
> > : this that
> >
> > Thanks for the suggestion and I hope the above is a sufficient
> > replacement for the now-missing #+BABEL: syntax.
> >
> > Cheers -- Eric
> 
> 

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Sebastien Vauban]

Hi Darlan,

Darlan Cavalcante Moreira wrote:
> It's excellent that now babel understands multiple values in the "var"
> property (I was one of the people that wanted this), but "There Is One More
> Thing".
>
> Would it be feasible to inherit variables from parent sub-trees?
> Effectively, I'd like to append new values in lower level sub-trees, but
> AFAIK setting the var property in a sub-tree will still replace the value
> set in the parent sub-tree.

#+PROPERTY:  var foo="level0"

* Overview

Global vars and local-to-this-subtree vars seem correctly handled.

Effectively, vars set in higher level trees are not passed correctly to the
code block.

* Test code
  :PROPERTIES:
  :var:      bar="level1"
  :END:

** Using the different vars
   :PROPERTIES:
   :var:      baz="level2"
   :END:

#+srcname: test
#+begin_src sh :var foo="valueforthiscodeblock"
echo $foo
echo $bar
echo $baz
#+end_src

#+results: test
| valueforthiscodeblock |
|                       |
| level2                |

As you can see, the "bar" variable is unknown to the code block.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Christian Moe]

On 10/21/11 8:40 PM, Rainer M Krug wrote:
>
>
> Just to add to it: at the moment I have e.g:
>
> #+BABEL: :var MAINVERSION=0
> #+BABEL: :var SVNVERSION=(vc-working-revision (buffer-file-name))
> #+BABEL: :var SVNSTATE=( symbol-name (vc-state (or (buffer-file-name)
> org-current-export-file)))
> #+BABEL: :var SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name)
> org-current-export-file)) 'up-to-date) 0 13)
> #+BABEL: :var DISP_PACKAGE="seedDisp_0.4-13.tar.gz"
>
> which would look horrible in one line and a nightmare to edit.
>
> Any suggestions how this cold be changed?

Wow. I guess I was wrong to imagine your problem was solved.

If your code blocks share the same language, and it supports sessions, 
I'd bite the bullet and transform them into #+HEADERS lines for the 
first src block, then reuse them through a session. Does that make sense?

If your variables are going to be used by different src blocks in 
different languages, I don't have any elegant solution.

Yours,
Christian

Re: [RFC] Standardized code block keywords

[Eric Schulte]

>
> Let me help revise the documentation when the dust settles and the
> syntax changes are in place.  As it stands now, #+data: doesn't show up
> in the index to the manual, and the entry for #+tblname: leads only to
> a description of its use in spreadsheets.
>

Thanks Tom, any help with the documentation will be much appreciated.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Eric Schulte]

>
> Just to clarify my understanding: on a #+PROPERTY line, you *have* to
> say
>
> #+PROPERTY: var a=1, b=2
>
> but in the code block itself, you can say *either*
>
> #+begin_src emacs-lisp :var a=1, b=2
> ...
>
>
> *or*
>
> #+begin_src emacs-lisp :var a=1 :var b=2
> ...
>

correct

>
> Experimentally, both of these currently work: do you have any plans to
> outlaw the last form?
>

no

>
> Also, how does the comma-separated list of variable assignments interact
> with a language where comma has syntactic significance? I was primarily
> thinking of python where e.g. a=[1,2,3] or a=(1,2) is a legal
> construct. AFAICT, that never worked in babel[fn:1], so it may not
> matter much, but it may be a good idea to come up with a quoting
> mechanism so things like that can be added in the future if necessary.
>

The syntax of the language is not used in the header argument form, only
code-block constructs are used here, which largely amounts to data and
code block references, indexing into variables, and emacs-lisp forms.
There are cases where the above do contain ", " but they are parsed
correctly, e.g.,

#+headers: :var data=foo(bar=1, baz=2), fuz=5

and

#+headers: :var data=table[0,0]

will both be parsed correctly.

>
> Thanks,
> Nick
>
> Footnotes:
>
> [fn:1] I checked in 7.7 to avoid the recent churn with the following
> code block
>
>
> #+begin_src python :var a='(1,2)'
> len(a)
> #+end_src
>
> and I get 
>
> ,----
> |   File "<stdin>", line 3
> |     a=[1, [\,, 2]]
> |                  ^
> | SyntaxError: unexpected character after line continuation character
> `----
>
> in the org babel error output buffer.

you can use elisp in assignment forms, but not syntax from the language
of the code block, so the above could be re-written as

#+begin_src python :var a='(1 2)
  len(a)
#+end_src

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Eric Schulte]

> Will
>
> #+PROPERTY: var foo=1
> #+PROPERTY: var bar=2
>
> also work, or result in one variable not signed?
>

Try it out :)

This is a question about property behavior not specific to code blocks.
I believe that the second line will override the first, which is why it
was necessary to be able to specify multiple variables in a single
#+PROPERTY: instance.

Cheers -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Eric Schulte]

>
> Just to add to it: at the moment I have e.g:
>
> #+BABEL: :var MAINVERSION=0
> #+BABEL: :var SVNVERSION=(vc-working-revision (buffer-file-name))
> #+BABEL: :var SVNSTATE=( symbol-name (vc-state (or (buffer-file-name) org-current-export-file)))
> #+BABEL: :var SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13)
> #+BABEL: :var DISP_PACKAGE="seedDisp_0.4-13.tar.gz"
>
> which would look horrible in one line and a nightmare to edit.
>
> Any suggestions how this cold be changed?
>

Hmm, I don't see any easy solution for the above.  I'm sorry to have
removed this functionality.

I can think of three options for how to handle this situation.

1. If it turns out to be possible/desirable my preferred solution here
   would be to add general property support for appending values to
   properties when properties are over specified rather than simply
   replacing the value.  Perhaps this could be done with a variable like
   org-accumulating-properties which could hold a list of those
   properties which should accumulate values rather than overwriting
   them.

2. Adding a "#+PROPERTY:" line authoring helper similar to the table
   formula helper making it more natural to edit such long property
   lines.

3. It may be possible to add syntax for extending #+PROPERTY:
   specifications across multiple lines, something like

   #+PROPERTY:  var MAINVERSION=0,
   #+PROPERTY+: SVNVERSION=(vc-working-revision (buffer-file-name)),
   #+PROPERTY+: SVNSTATE=( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))),
   #+PROPERTY+: SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13),
   #+PROPERTY+: DISP_PACKAGE="seedDisp_0.4-13.tar.gz"

   FWIW I would like to have a similar extender for #+TBLFM: lines.
   Actually this choice may be my preferred solution.

What do you think?

>
> In addition: I would like to have a warning if #+BABEL is present in the org
> file, so that one remembers that it has to be changed.
>

#+begin_src emacs-lisp
  (add-hook 'org-mode-hook
            (lambda ()
              (save-excursion
                (goto-char (point-min))
                (when (re-search-forward (org-make-options-regexp '("BABEL")))
                  (message "This file contains a \"#+BABEL:\" line.")))))
#+end_src

Cheers -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Eric Schulte]

Darlan Cavalcante Moreira <darcamo@gmail.com> writes:

> It's excellent that now babel understands multiple values in the "var"
> property (I was one of the people that wanted this), but "There Is One More
> Thing".
>
> Would it be feasible to inherit variables from parent sub-trees?
> Effectively, I'd like to append new values in lower level sub-trees, but
> AFAIK setting the var property in a sub-tree will still replace the value
> set in the parent sub-tree.
>

Currently every new property specification entirely replaced previous
specifications with the same name.

>
> That is, in the example below the level-2 sub-trees would not have the foo
> variable passed to babel.
> * Code with foo
>   :PROPERTIES:
>   :var:      foo=1
>   :END:
>
> ** Code only with bar
>    :PROPERTIES:
>    :var:      bar=2
>    :END:
>    src_block
> ** Code only with baz
>    :PROPERTIES:
>    :var:      baz=3
>    :END:
>    src_block
>
> Maybe a special keyword, such as "inherit" (or "append") could be used to
> incorporate variables defined in the parent sub-tree, such that the example
> would become
> * Code with foo
>   :PROPERTIES:
>   :var:      foo=1
>   :END:
>
> ** Code with foo and bar
>    :PROPERTIES:
>    :var:      bar=2, inherit
>    :END:
>    src_block
> ** Code with foo and baz
>    :PROPERTIES:
>    :var:      baz=3, inherit
>    :END:
>    src_block
>
> This should not affect global variables and "inherit" would inherit
> variables defined only in the parent sub-tree (unless it also contains the
> inherit keyword).
>
> As a use case scenario, suppose I need to perform simulations for a few
> different scenarios, each with small variations. This would allow me to
> define common variables for a scenario in a higher level sub-tree and more
> specific variables in the lower level sub-trees.
>

This sounds somewhat similar to my suggestion in reply to Rainer's
email.

Best -- Eric

>
> --
> Darlan Cavalcante
>
>
> At Fri, 21 Oct 2011 22:24:25 +0200,
> Christian Moe <mail@christianmoe.com> wrote:
>> 
>> Hi,
>> 
>> Yes, that works nicely, and should solve Rainer's problem.
>> I haven't been able to think of anything else that can't be handled by 
>> properties.
>> 
>> And I do think it's a good idea to winnow down the syntax a bit, even 
>> if things break. I just like to grumble.
>> :-)
>> 
>> Yours,
>> Christian
>> 
>> On 10/21/11 7:37 PM, Eric Schulte wrote:
>> > Nice idea.  This same issue with "var" arose when we first started
>> > allowing header arguments to be specified inside subtree properties.
>> > I've just implemented your suggestion so the following are now possible.
>> >
>> > #+PROPERTY: var foo=1, bar=2
>> > #+PROPERTY: cache yes
>> >
>> > #+begin_src emacs-lisp
>> >    (+ foo bar)
>> > #+end_src
>> >
>> > #+results[be32e67491d4e92f75769aebe423c20ca01626fe]:
>> > : 3
>> >
>> > and
>> >
>> > #+begin_src emacs-lisp :var foo="this", bar="that"
>> >    (concat foo " " bar)
>> > #+end_src
>> >
>> > #+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]:
>> > : this that
>> >
>> > Thanks for the suggestion and I hope the above is a sufficient
>> > replacement for the now-missing #+BABEL: syntax.
>> >
>> > Cheers -- Eric
>> 
>> 

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Christian Moe]

Hi,

Eric Schulte wrote:
>

> I can think of three options for how to handle this situation.
>
> 1. If it turns out to be possible/desirable my preferred solution
> here would be to add general property support for appending values
> to properties when properties are over specified
(...)
>
> 2. Adding a "#+PROPERTY:" line authoring helper similar to the
> table formula helper making it more natural to edit such long
> property lines.
>
> 3. It may be possible to add syntax for extending #+PROPERTY:
> specifications across multiple lines, something like
>
> #+PROPERTY: var MAINVERSION=0,
 > #+PROPERTY+: SVNVERSION=(vc-working-revision (buffer-file-name)),
(...)

These are all interesting ideas, as was Darlan's alternative 
suggestion to Eric's suggestion (1), namely to use a special inherit 
argument.

I'd like to toss out a different idea, which I think is brilliant, but 
which may go down in flames once we've had a time to think it through. 
(And sorry if it's been proposed before; I came to Org just as 
Org-Babel was being stabilized.)

In short, let Babel assign to any declared variables of a src block 
the values of any properties at point with the same name. In other words:

- The :var header argument / :var: property could declare variables 
without assigning values, that is, you could have
`:var foo=1, bar, baz=3' to tell Babel that `bar' is a variable too.

- When a variable is declared, but no value assigned, Babel would look 
for a property (e.g. `:bar: 2') at point with the same name as the 
variable.

- If property inheritance is turned on, this means a variable can be 
specified at any level of the outline.

- If no further changes were made (such as the property accumulation 
Eric suggested), it would still be possible to /declare/ variables 
only at /one/ level of the outline besides in the code block and 
calls, since declarations all belong to the same `:var:' property. 
However, this approach would mean that declarations could be kept 
short and there would be a great deal of modularity in what values 
would be assigned.

Two examples follow.

---

Example 1.

Darlan suggested a special "inherit" argument, as follows:

* Code with foo
   :PROPERTIES:
   :var:      foo=1
   :END:

** Code with foo and bar
    :PROPERTIES:
    :var:      bar=2, inherit
    :END:
    src_block
** Code with foo and baz
    :PROPERTIES:
    :var:      baz=3, inherit
    :END:
    src_block


Here is the same example under my proposal and with property 
inheritance turned on:

* Code with foo
   :PROPERTIES:
   :foo:      1
   :END:

** Code with foo and bar
    :PROPERTIES:
    :bar:      2
    :END:

    src_block :var foo, bar

** Code with foo and baz
    :PROPERTIES:
    :baz:      3
    :END:

    src_block :var foo, baz

Instead of declaring foo,bar and foo,baz in the src_blocks, we could 
define them once and for all at the top of the outline:

* Code with foo
   :PROPERTIES:
   :foo:      1
   :var: foo, bar, baz
   :END:

** Code with foo and bar
    :PROPERTIES:
    :bar:      2
    :END:

    src_block

** Code with foo and baz
    :PROPERTIES:
    :baz:      3
    :END:

    src_block

Under the first subhead, Org-babel would know (because the :var: 
property is inherited) to look for foo, bar and baz properties. It 
would find values for foo and bar (bar is defined as a property of 
that subhead, foo is inherited from the top-level heading). It would 
not find any value for baz. At this point, since no value could be 
assigned to baz, it would be ignored and would not be passed to the 
code block.

---

Example 2.

Let's take Rainer's problem :

On 10/22/11 5:52 PM, Eric Schulte wrote:
>>
>> #+BABEL: :var MAINVERSION=0
>> #+BABEL: :var SVNVERSION=(vc-working-revision (buffer-file-name))
>> #+BABEL: :var SVNSTATE=( symbol-name (vc-state (or (buffer-file-name) org-current-export-file)))
>> #+BABEL: :var SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13)
>> #+BABEL: :var DISP_PACKAGE="seedDisp_0.4-13.tar.gz"
>>

Have a buffer-level property for all the long lines (sorry if my email 
client wraps these lines):

#+PROPERTY: SVNVERSION (vc-working-revision (buffer-file-name))
#+PROPERTY: SVNSTATE ( symbol-name (vc-state (or (buffer-file-name) 
org-current-export-file)))
#+PROPERTY: SVNSTATENUM (if (eq (vc-state (or (buffer-file-name) 
org-current-export-file)) 'up-to-date) 0 13)
#+PROPERTY: DISP_PACKAGE "seedDisp_0.4-13.tar.gz"

Also, we have a buffer-level line declaring all these variables, and 
including MAINVERSION with the ordinary assignment. Thanks to last 
night's change, we can list them all on one line.

#+PROPERTY: var MAINVERSION=0, SVNVERSION, SVNSTATE, SVNSTATENUM, 
DISP_PACKAGE

I don't know what kind of code this example applies to, but let's 
imagine that we also have a header that resets one of these properties:

* Variant for main version 1
   :PROPERTIES:
   :MAINVERSION: 1
   :END:

...and below that, we finally have a code block, with a header that 
declares a variable locally:

#+HEADERS: :var somelocalvar="something or other"
#+BEGIN_SRC Perl
   while(...) {
      ...
   }
#+END_SRC

This should expand to something like:

#!/usr/bin/perl
use warnings;
my $MAINVERSION = 1;
my $SVNVERSION = "0.4.13";
my $SVNSTATE = "something or other"
my $SVNSTATENUM = 13;
my $DISP_PACKAGE = "seedDisp_0.4-13.tar.gz";
my $somelocalvar = "something or other";
while(...) {
    ...
}

---

OK, hopefully my idea is clear by now.

Could it be made to work?
Would it solve some problems?
Would it mess other things up even worse?

Yours,
Christian

Re: [RFC] Standardized code block keywords

[Daniel Bausch]

Am Freitag, 21. Oktober 2011, 21:10:27 schrieb Thomas S. Dye:
> Eric Schulte <schulte.eric@gmail.com> writes:
> >>> I'm confused by [3] so I will say nothing for now, except to ask some
> >>> questions: are we talking about what a human would use to label a piece
> >>> of data for consumption by a block (including perhaps the future
> >>> possibilities of lists and paragraphs that Tom brought up)? what babel
> >>> would use to label a results block (possibly so that it could be
> >>> consumed by another block in a chain)? both? would that mean
> >>> that #+tblname would go the way of the dodo and that tables would be
> >>> labelled with #+data (or #+object or whatever else we come up with)?
> >> 
> >> +1 (Confused, too)
> > 
> > well, I guess it is good that this discussion has begun if only to clear
> > up this lingering uncertainty.
> > 
> >> I wasn't even aware of #+DATA. Does it do anything TBLNAME and SRCNAME
> >> don't?
> > 
> > from the prospective of code blocks it is exactly synonymous with
> > tblname.  Srcname is different in that it labels code blocks.
> > 
> >> A reason to keep TBLNAME is that it's also used by the spreadsheet
> >> remote references. If Babel looked for DATA instead, a table that is
> >> both a remote reference for another spreadsheet and a data source for
> >> a src block would need both TBLNAME and DATA, which seems redundant.
> > 
> > agreed, I'm thinking that tblname will at least remain an option no
> > matter what decision is made.
> > 
> >> As for labeling lists and paragraphs, I recall from the list that
> >> Nicolas Goaziou is working on a generalized way to set captions,
> >> labels and attributes for various kinds of Org block, as is possible
> >> now for tables and images. I thought that sounded promising. I don't
> >> know if he planned for block names, too (currently we have tblname but
> >> no imgname), but that could make sense. In which case it might be a
> >> good idea to coordinate.
> > 
> > Agreed, I was not aware of this work.  Thanks for sharing.  In this vein
> > I would like to voice my desire to be able to add captions to code
> > blocks, the lack of this feature has bitten me in the past.
> 
> Hi Eric,
> 
> For LaTeX export, the listings package has support for code block
> captions.

Not in org AFAIK, org only supports these for my use cases not very useful 
"function name = " exports.  I patched org to produce real captions instead, 
but my changes are not that well tested and required some changes in the 
central export logic.  If there is interest I could share what I have so far.  
The code quality is a mess, as I do not really know elisp.

Daniel

Re: [RFC] Standardized code block keywords

[Daniel Bausch]

Hi,

>          named code blocks [1] -- "source" "srcname" "function"
> calling external functions [2] -- "call" "lob"
>                 named data [3] -- "tblname" "resname" "results" "data"

what about "#+name:" for [1] and [3], and "#+call:" for [2] ?

That a table or list contains data is obvious.  The only thing, the additional 
line is for, is to "name" it.  That a source block contains source is also 
obvious and is already noted by the use of #+begin_src, so why duplicate the 
"src"-part?

Daniel

Re: [RFC] Standardized code block keywords

[Thomas S. Dye]

Daniel Bausch <DanielBausch@gmx.de> writes:

> Am Freitag, 21. Oktober 2011, 21:10:27 schrieb Thomas S. Dye:
>> Eric Schulte <schulte.eric@gmail.com> writes:
>> >>> I'm confused by [3] so I will say nothing for now, except to ask some
>> >>> questions: are we talking about what a human would use to label a piece
>> >>> of data for consumption by a block (including perhaps the future
>> >>> possibilities of lists and paragraphs that Tom brought up)? what babel
>> >>> would use to label a results block (possibly so that it could be
>> >>> consumed by another block in a chain)? both? would that mean
>> >>> that #+tblname would go the way of the dodo and that tables would be
>> >>> labelled with #+data (or #+object or whatever else we come up with)?
>> >> 
>> >> +1 (Confused, too)
>> > 
>> > well, I guess it is good that this discussion has begun if only to clear
>> > up this lingering uncertainty.
>> > 
>> >> I wasn't even aware of #+DATA. Does it do anything TBLNAME and SRCNAME
>> >> don't?
>> > 
>> > from the prospective of code blocks it is exactly synonymous with
>> > tblname.  Srcname is different in that it labels code blocks.
>> > 
>> >> A reason to keep TBLNAME is that it's also used by the spreadsheet
>> >> remote references. If Babel looked for DATA instead, a table that is
>> >> both a remote reference for another spreadsheet and a data source for
>> >> a src block would need both TBLNAME and DATA, which seems redundant.
>> > 
>> > agreed, I'm thinking that tblname will at least remain an option no
>> > matter what decision is made.
>> > 
>> >> As for labeling lists and paragraphs, I recall from the list that
>> >> Nicolas Goaziou is working on a generalized way to set captions,
>> >> labels and attributes for various kinds of Org block, as is possible
>> >> now for tables and images. I thought that sounded promising. I don't
>> >> know if he planned for block names, too (currently we have tblname but
>> >> no imgname), but that could make sense. In which case it might be a
>> >> good idea to coordinate.
>> > 
>> > Agreed, I was not aware of this work.  Thanks for sharing.  In this vein
>> > I would like to voice my desire to be able to add captions to code
>> > blocks, the lack of this feature has bitten me in the past.
>> 
>> Hi Eric,
>> 
>> For LaTeX export, the listings package has support for code block
>> captions.
>
> Not in org AFAIK, org only supports these for my use cases not very useful 
> "function name = " exports.  I patched org to produce real captions instead, 
> but my changes are not that well tested and required some changes in the 
> central export logic.  If there is interest I could share what I have so far.  
> The code quality is a mess, as I do not really know elisp.
>
> Daniel
>
>

Yes, source code block captions currently have to be handled outside the
usual Org-mode mechanism.  If you use org-special-blocks and the
listings package, then the following template will give you floating
code block listings with captions in LaTeX export.

 : #+BEGIN_listing
 :  <source block>
 : #+LATEX: \caption[The short caption]{The long caption.}\ref{fig:src_blk}
 : #+END_listing

This doesn't do anything for export to other formats, but it works well
for LaTeX export.  There is even \listoflistings command to produce a
list of source code listings in the front matter.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [RFC] Standardized code block keywords

[Torsten Wagner]

Hi Eric,
Hi Seb,

>
> Eric Schulte wrote:
>>> We could open an older file and if it isn't working, we could try
>>>
>>> #+PROPERTY: babel-function-set obsolete
>>
>> I think that making use of such a feature is almost as onerous as
>> changing to the new terms (which is a simple search replace, in fact
>> once terms are selected I'll happily share a function on list which can
>> be used to convert all old terms in existing Org-mode files).

Ok, I agree with both of you. Keeping obsolete functions active might be 
more difficult then just asking people to change the tiny bits and 
pieces. I like the idea to having a function to convert old syntax to 
new syntax (semi)automatically.
Python did the same with there 2to3 script and I was able to convert 
large parts of my scripts without problems.

Only make sure that the BIG BANG is really loud reaching all babelers 
out there (including the ones not on this mailing list and not reading 
changelogs)

Maybe an additional function could be called for a certain time whenever 
old syntax is found (just a list of keywords) generating a warning that 
this code is obsolete pointing to a special chapter in the manual to 
help with conversion. That would help people to understand what is going 
on rather then getting a standard error message for code which run 
perfectly fine a few months ago. Remember, people might upgrade to 
emacs24 and they might not be aware that this includes updates to 
org-mode and org-babel.

Anyhow I would like to offer to help with the manual (my lisp is to poor 
to help with coding). There should be a new section which helps 
old-babeler to change there code to the newest syntax, explain shortly 
changes in the syntax, etc. A two column table is often used for this
| old syntax | replaced now by |
| #+BABEL:   | #+ PROPERTIES   |
Followed by some more explanation or a link to the (rewritten) manual 
section.

Totti

Re: [RFC] Standardized code block keywords

[Daniel Bausch]

[-- Attachment #1: Type: Text/Plain, Size: 4465 bytes --]

Am Sonntag 23 Oktober 2011, 18:09:01 schrieben Sie:
> Daniel Bausch <DanielBausch@gmx.de> writes:
> > Am Freitag, 21. Oktober 2011, 21:10:27 schrieb Thomas S. Dye:
> >> Eric Schulte <schulte.eric@gmail.com> writes:
> >> >>> I'm confused by [3] so I will say nothing for now, except to ask
> >> >>> some questions: are we talking about what a human would use to
> >> >>> label a piece of data for consumption by a block (including perhaps
> >> >>> the future possibilities of lists and paragraphs that Tom brought
> >> >>> up)? what babel would use to label a results block (possibly so
> >> >>> that it could be consumed by another block in a chain)? both? would
> >> >>> that mean that #+tblname would go the way of the dodo and that
> >> >>> tables would be labelled with #+data (or #+object or whatever else
> >> >>> we come up with)?
> >> >> 
> >> >> +1 (Confused, too)
> >> > 
> >> > well, I guess it is good that this discussion has begun if only to
> >> > clear up this lingering uncertainty.
> >> > 
> >> >> I wasn't even aware of #+DATA. Does it do anything TBLNAME and
> >> >> SRCNAME don't?
> >> > 
> >> > from the prospective of code blocks it is exactly synonymous with
> >> > tblname.  Srcname is different in that it labels code blocks.
> >> > 
> >> >> A reason to keep TBLNAME is that it's also used by the spreadsheet
> >> >> remote references. If Babel looked for DATA instead, a table that is
> >> >> both a remote reference for another spreadsheet and a data source for
> >> >> a src block would need both TBLNAME and DATA, which seems redundant.
> >> > 
> >> > agreed, I'm thinking that tblname will at least remain an option no
> >> > matter what decision is made.
> >> > 
> >> >> As for labeling lists and paragraphs, I recall from the list that
> >> >> Nicolas Goaziou is working on a generalized way to set captions,
> >> >> labels and attributes for various kinds of Org block, as is possible
> >> >> now for tables and images. I thought that sounded promising. I don't
> >> >> know if he planned for block names, too (currently we have tblname
> >> >> but no imgname), but that could make sense. In which case it might
> >> >> be a good idea to coordinate.
> >> > 
> >> > Agreed, I was not aware of this work.  Thanks for sharing.  In this
> >> > vein I would like to voice my desire to be able to add captions to
> >> > code blocks, the lack of this feature has bitten me in the past.
> >> 
> >> Hi Eric,
> >> 
> >> For LaTeX export, the listings package has support for code block
> >> captions.
> > 
> > Not in org AFAIK, org only supports these for my use cases not very
> > useful "function name = " exports.  I patched org to produce real
> > captions instead, but my changes are not that well tested and required
> > some changes in the central export logic.  If there is interest I could
> > share what I have so far. The code quality is a mess, as I do not really
> > know elisp.
> > 
> > Daniel
> 
> Yes, source code block captions currently have to be handled outside the
> usual Org-mode mechanism.  If you use org-special-blocks and the
> listings package, then the following template will give you floating
> code block listings with captions in LaTeX export.
> 
>  : #+BEGIN_listing
>  : 
>  :  <source block>
>  : 
>  : #+LATEX: \caption[The short caption]{The long caption.}\ref{fig:src_blk}
>  : #+END_listing
> 
> This doesn't do anything for export to other formats, but it works well
> for LaTeX export.  There is even \listoflistings command to produce a
> list of source code listings in the front matter.
> 
> All the best,
> Tom

Thank you for this hint, but with my patches, I'm able to write 

#+caption: A Code Snippet
#+label: lst:xyz
#+begin_src lang
#+end_src

What I'd like to add, is that the listings implementation in org has a bug, 
which I also fixed.  If you mix #+begin_src and #+begin_example blocks in one 
document, then the #+begin_example blocks are syntax highlighted analog to the 
previous #+begin_src block because the language is selected by \lstset.
In my patches I'm using the 'language' attribute of \begin{lstlisting}, which 
does not affect following blocks that do not have this attribute.

I have attached my patch.  I suspect that there might be a bug in it, that 
disables that tables that have #+attr_latex can be used by babel using 
#+tblname, because I observed such a behavior recently.  It is possible that 
this second defect might origin from somewhere else, too.

Daniel

[-- Attachment #2: org-exp_caption.patch --]
[-- Type: text/x-patch, Size: 6950 bytes --]

diff --git a/lisp/org-exp.el b/lisp/org-exp.el
index 2aad322..8255021 100644
--- a/lisp/org-exp.el
+++ b/lisp/org-exp.el
@@ -1171,7 +1171,15 @@ on this string to produce the exported version."
       ;; Export code blocks
       (org-export-blocks-preprocess)
 
+      ;; Select and protect backend specific stuff, throw away stuff
+      ;; that is specific for other backends
+      (run-hooks 'org-export-preprocess-before-selecting-backend-code-hook)
+      (org-export-select-backend-specific-text)
+
+      ;; Attach captions to the correct object
+      (setq target-alist (org-export-attach-captions-and-attributes target-alist))
       ;; Mark lists with properties
+
       (org-export-mark-list-properties)
 
       ;; Handle source code snippets
@@ -1213,11 +1221,6 @@ on this string to produce the exported version."
       ;; but mark them as targets that should be invisible
       (setq target-alist (org-export-handle-invisible-targets target-alist))
 
-      ;; Select and protect backend specific stuff, throw away stuff
-      ;; that is specific for other backends
-      (run-hooks 'org-export-preprocess-before-selecting-backend-code-hook)
-      (org-export-select-backend-specific-text)
-
       ;; Protect quoted subtrees
       (org-export-protect-quoted-subtrees)
 
@@ -1235,9 +1238,6 @@ on this string to produce the exported version."
       (unless (plist-get parameters :timestamps)
 	(org-export-remove-timestamps))
 
-      ;; Attach captions to the correct object
-      (setq target-alist (org-export-attach-captions-and-attributes target-alist))
-
       ;; Find matches for radio targets and turn them into internal links
       (org-export-mark-radio-links)
       (run-hooks 'org-export-preprocess-after-radio-targets-hook)
@@ -1894,7 +1894,11 @@ table line.  If it is a link, add it to the line containing the link."
 		    "\\|"
 		    "^[ \t]*\\(|[^-]\\)"
 		    "\\|"
-		    "^[ \t]*\\[\\[.*\\]\\][ \t]*$"))
+		    "^[ \t]*\\[\\[.*\\]\\][ \t]*$"
+		    "\\|"
+		    "^[ \t]*#\\+begin_src.*$"
+		    "\\|"
+		    "^[ \t]*#\\+begin_example.*$"))
 	cap shortn attr label end)
     (while (re-search-forward re nil t)
       (cond
@@ -2468,7 +2472,7 @@ in the list) and remove property and value from the list in LISTVAR."
   "Replace source code segments with special code for export."
   (setq org-export-last-code-line-counter-value 0)
   (let ((case-fold-search t)
-	lang code trans opts indent caption)
+	lang code trans opts indent caption label attr)
     (goto-char (point-min))
     (while (re-search-forward
 	    "\\(^\\([ \t]*\\)#\\+BEGIN_SRC:?\\([ \t]+\\([^ \t\n]+\\)\\)?\\(.*\\)\n\\([^\000]+?\n\\)[ \t]*#\\+END_SRC.*\n?\\)\\|\\(^\\([ \t]*\\)#\\+BEGIN_EXAMPLE:?\\(?:[ \t]+\\(.*\\)\\)?\n\\([^\000]+?\n\\)[ \t]*#\\+END_EXAMPLE.*\n?\\)"
@@ -2489,15 +2493,19 @@ in the list) and remove property and value from the list in LISTVAR."
 		  opts (match-string 5)
 		  code (match-string 6)
 		  indent (length (match-string 2))
-		  caption (get-text-property 0 'org-caption (match-string 0))))
+		  caption (get-text-property 0 'org-caption (match-string 0))
+		  label (get-text-property 0 'org-label (match-string 0))
+		  attr (get-text-property 0 'org-attributes (match-string 0))))
 	(setq lang nil
 	      opts (match-string 9)
 	      code (match-string 10)
 	      indent (length (match-string 8))
-              caption (get-text-property 0 'org-caption (match-string 0))))
+              caption (get-text-property 0 'org-caption (match-string 0))
+	      label (get-text-property 0 'org-label (match-string 0))
+	      attr (get-text-property 0 'org-attributes (match-string 0))))
 
       (setq trans (org-export-format-source-code-or-example
-		   lang code opts indent caption))
+		   lang code opts indent caption label attr))
       (replace-match trans t t))))
 
 (defvar org-export-latex-verbatim-wrap) ;; defined in org-latex.el
@@ -2519,7 +2527,7 @@ in the list) and remove property and value from the list in LISTVAR."
       (forward-char 1))))
 
 (defun org-export-format-source-code-or-example
-  (lang code &optional opts indent caption)
+  (lang code &optional opts indent caption label attr)
   "Format CODE from language LANG and return it formatted for export.
 The CODE is marked up in `org-export-current-backend' format.
 
@@ -2664,13 +2672,13 @@ INDENT was the original indentation of the block."
 	     ((eq org-export-current-backend 'latex)
 	      (setq rtn (org-export-number-lines rtn 0 0 num cont rpllbl fmt))
 	      (cond
-	       ((and lang org-export-latex-listings)
+	       (org-export-latex-listings
 		(flet ((make-option-string
 			(pair)
 			(concat (first pair)
 				(if (> (length (second pair)) 0)
 				    (concat "=" (second pair))))))
-		  (let* ((lang-sym (intern lang))
+		  (let* ((lang-sym (cond (lang (intern lang)) (t nil)))
 			 (minted-p (eq org-export-latex-listings 'minted))
 			 (listings-p (not minted-p))
 			 (backend-lang
@@ -2687,13 +2695,6 @@ INDENT was the original indentation of the block."
 			    lang-sym
 			    org-export-latex-custom-lang-environments))))
 		    (concat
-		     (when (and listings-p (not custom-environment))
-		       (format
-			"\\lstset{%s}\n"
-			(mapconcat
-			 #'make-option-string
-			 (append org-export-latex-listings-options
-				 `(("language" ,backend-lang))) ",")))
 		     (when (and caption org-export-latex-listings-w-names)
 		       (format
 			"\n%s $\\equiv$ \n"
@@ -2703,8 +2704,26 @@ INDENT was the original indentation of the block."
 		       (format "\\begin{%s}\n%s\\end{%s}\n"
 			       custom-environment rtn custom-environment))
 		      (listings-p
-		       (format "\\begin{%s}\n%s\\end{%s}"
-			       "lstlisting" rtn "lstlisting"))
+		       (concat
+			"\\begin{lstlisting}"
+			(when (or (and caption (not org-export-latex-listings-w-names)) attr label backend-lang org-export-latex-listings-options) "[")
+			(when org-export-latex-listings-options
+			  (mapconcat
+			   #'make-option-string
+			   org-export-latex-listings-options ","))
+			(when (and org-export-latex-listings-options (or (and caption (not org-export-latex-listings-w-names)) attr label backend-lang)) ",")
+			(when backend-lang (concat "language=" backend-lang))
+			(when (and backend-lang (or (and caption (not org-export-latex-listings-w-names)) attr label)) ",")
+			(when (and caption (not org-export-latex-listings-w-names))
+			  (format "caption={%s}" (replace-regexp-in-string "_" "\\\\_" caption)))
+			(when (and caption (not org-export-latex-listings-w-names) label) ",")
+			(when label (format "label=%s" label))
+			(when (and (or (and caption (not org-export-latex-listings-w-names)) label) attr) ",")
+			attr
+			(when (or (and caption (not org-export-latex-listings-w-names)) attr label backend-lang org-export-latex-listings-options) "]")
+			"\n"
+			rtn 
+			"\\end{lstlisting}\n"))
 		      (minted-p
 		       (format
 			"\\begin{minted}[%s]{%s}\n%s\\end{minted}"

Re: [RFC] Standardized code block keywords

[Eric S Fraga]

Daniel Bausch <DanielBausch@gmx.de> writes:

> Hi,
>
>>          named code blocks [1] -- "source" "srcname" "function"
>> calling external functions [2] -- "call" "lob"
>>                 named data [3] -- "tblname" "resname" "results" "data"
>
> what about "#+name:" for [1] and [3], and "#+call:" for [2] ?
>
> That a table or list contains data is obvious.  The only thing, the additional 
> line is for, is to "name" it.  That a source block contains source is also 
> obvious and is already noted by the use of #+begin_src, so why duplicate the 
> "src"-part?
>
> Daniel

I don't know if I've left it too late to vote on this but...

I would go for "name" for [1] and [3] and "call" for [2].

I can, however, see the need for distinguishing between data tables and
results so could be convinced that "data" and "results" should be used
for [3].  In any case, I do know that I dislike srcname and tblname...

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1
: using Org-mode version 7.7 (release_7.7.452.g767f5)

Re: [RFC] Standardized code block keywords

[Sebastien Vauban]

Hi Daniel,

Daniel Bausch wrote:
>>          named code blocks [1] -- "source" "srcname" "function"
>> calling external functions [2] -- "call" "lob"
>>                 named data [3] -- "tblname" "resname" "results" "data"
>
> what about "#+name:" for [1] and [3], and "#+call:" for [2] ?
>
> That a table or list contains data is obvious.  The only thing, the additional 
> line is for, is to "name" it.

As Eric showed us, this is not always to name it... If the table is the
results of an unamed block, you will have #+name: followed by no name!

#+name:
| line 1 | data1 |
| line 2 | data2 |

what I also find quite disturbing.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]

On Sat, Oct 22, 2011 at 9:58 AM, Christian Moe <mail@christianmoe.com>wrote:

> On 10/21/11 8:40 PM, Rainer M Krug wrote:
>
>>
>>
>> Just to add to it: at the moment I have e.g:
>>
>> #+BABEL: :var MAINVERSION=0
>> #+BABEL: :var SVNVERSION=(vc-working-**revision (buffer-file-name))
>> #+BABEL: :var SVNSTATE=( symbol-name (vc-state (or (buffer-file-name)
>> org-current-export-file)))
>> #+BABEL: :var SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name)
>> org-current-export-file)) 'up-to-date) 0 13)
>> #+BABEL: :var DISP_PACKAGE="seedDisp_0.4-13.**tar.gz"
>>
>> which would look horrible in one line and a nightmare to edit.
>>
>> Any suggestions how this cold be changed?
>>
>
> Wow. I guess I was wrong to imagine your problem was solved.
>
> If your code blocks share the same language, and it supports sessions, I'd
> bite the bullet and transform them into #+HEADERS lines for the first src
> block, then reuse them through a session. Does that make sense?
>
> If your variables are going to be used by different src blocks in different
> languages, I don't have any elegant solution.
>

Yep - different languages: R and sh



>
> Yours,
> Christian
>
>
>
>
>
>
>
>
>
>
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax (F):       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

[-- Attachment #2: Type: text/html, Size: 2405 bytes --]

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 3695 bytes --]

On Sat, Oct 22, 2011 at 5:52 PM, Eric Schulte <schulte.eric@gmail.com>wrote:

> >
> > Just to add to it: at the moment I have e.g:
> >
> > #+BABEL: :var MAINVERSION=0
> > #+BABEL: :var SVNVERSION=(vc-working-revision (buffer-file-name))
> > #+BABEL: :var SVNSTATE=( symbol-name (vc-state (or (buffer-file-name)
> org-current-export-file)))
> > #+BABEL: :var SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name)
> org-current-export-file)) 'up-to-date) 0 13)
> > #+BABEL: :var DISP_PACKAGE="seedDisp_0.4-13.tar.gz"
> >
> > which would look horrible in one line and a nightmare to edit.
> >
> > Any suggestions how this cold be changed?
> >
>
> Hmm, I don't see any easy solution for the above.  I'm sorry to have
> removed this functionality.
>
> I can think of three options for how to handle this situation.
>
> 1. If it turns out to be possible/desirable my preferred solution here
>   would be to add general property support for appending values to
>   properties when properties are over specified rather than simply
>   replacing the value.  Perhaps this could be done with a variable like
>   org-accumulating-properties which could hold a list of those
>   properties which should accumulate values rather than overwriting
>   them.
>

Should work, but will add an additional level of complexity which I think is
avoidable.


>
> 2. Adding a "#+PROPERTY:" line authoring helper similar to the table
>   formula helper making it more natural to edit such long property
>   lines.
>

I think this might be to complicated


>
> 3. It may be possible to add syntax for extending #+PROPERTY:
>   specifications across multiple lines, something like
>
>   #+PROPERTY:  var MAINVERSION=0,
>   #+PROPERTY+: SVNVERSION=(vc-working-revision (buffer-file-name)),
>   #+PROPERTY+: SVNSTATE=( symbol-name (vc-state (or (buffer-file-name)
> org-current-export-file))),
>   #+PROPERTY+: SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name)
> org-current-export-file)) 'up-to-date) 0 13),
>   #+PROPERTY+: DISP_PACKAGE="seedDisp_0.4-13.tar.gz"
>
>   FWIW I would like to have a similar extender for #+TBLFM: lines.
>   Actually this choice may be my preferred solution.
>

I like that suggestion - This would add an option, if inheritance for
subtrees is incorporated for #+PROPERTY to unset all variables - something I
was looking for some time ago.

So I really like that solution: logical, clear, does not break anything, and
easy to read - I would say go for it.

>
> What do you think?
>
> >
> > In addition: I would like to have a warning if #+BABEL is present in the
> org
> > file, so that one remembers that it has to be changed.
> >
>
> #+begin_src emacs-lisp
>  (add-hook 'org-mode-hook
>            (lambda ()
>              (save-excursion
>                (goto-char (point-min))
>                (when (re-search-forward (org-make-options-regexp
> '("BABEL")))
>                  (message "This file contains a \"#+BABEL:\" line.")))))
> #+end_src
>

Could this be included in the next few versions of org, as I can imnagine
that especially infrequent org-babel users will be confused. Also: in a
year, when I open an old org-file and it des not work, this would warn me
about the necessary modifications.


Cheers,

Rainer


>
> Cheers -- Eric
>
> --
> Eric Schulte
> http://cs.unm.edu/~eschulte/
>



-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax (F):       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

[-- Attachment #2: Type: text/html, Size: 5217 bytes --]

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 4996 bytes --]

On Sat, Oct 22, 2011 at 9:07 PM, Christian Moe <mail@christianmoe.com>wrote:

> Hi,
>
>
> Eric Schulte wrote:
>
>>
>>
>  I can think of three options for how to handle this situation.
>>
>> 1. If it turns out to be possible/desirable my preferred solution
>> here would be to add general property support for appending values
>> to properties when properties are over specified
>>
> (...)
>
>
>> 2. Adding a "#+PROPERTY:" line authoring helper similar to the
>> table formula helper making it more natural to edit such long
>> property lines.
>>
>> 3. It may be possible to add syntax for extending #+PROPERTY:
>> specifications across multiple lines, something like
>>
>> #+PROPERTY: var MAINVERSION=0,
>>
> > #+PROPERTY+: SVNVERSION=(vc-working-**revision (buffer-file-name)),
> (...)
>
> These are all interesting ideas, as was Darlan's alternative suggestion to
> Eric's suggestion (1), namely to use a special inherit argument.
>
> I'd like to toss out a different idea, which I think is brilliant, but
> which may go down in flames once we've had a time to think it through. (And
> sorry if it's been proposed before; I came to Org just as Org-Babel was
> being stabilized.)
>
> In short, let Babel assign to any declared variables of a src block the
> values of any properties at point with the same name. In other words:
>
> - The :var header argument / :var: property could declare variables without
> assigning values, that is, you could have
> `:var foo=1, bar, baz=3' to tell Babel that `bar' is a variable too.
>
> - When a variable is declared, but no value assigned, Babel would look for
> a property (e.g. `:bar: 2') at point with the same name as the variable.
>
> - If property inheritance is turned on, this means a variable can be
> specified at any level of the outline.
>
> - If no further changes were made (such as the property accumulation Eric
> suggested), it would still be possible to /declare/ variables only at /one/
> level of the outline besides in the code block and calls, since declarations
> all belong to the same `:var:' property. However, this approach would mean
> that declarations could be kept short and there would be a great deal of
> modularity in what values would be assigned.



This all sounds very interesting, but I have problems understanding the
advantages - possibly because I only had one coffee this morning. In
addition see further down:

SNIP


> On 10/22/11 5:52 PM, Eric Schulte wrote:
>
>>
>>> #+BABEL: :var MAINVERSION=0
>>> #+BABEL: :var SVNVERSION=(vc-working-**revision (buffer-file-name))
>>> #+BABEL: :var SVNSTATE=( symbol-name (vc-state (or (buffer-file-name)
>>> org-current-export-file)))
>>> #+BABEL: :var SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name)
>>> org-current-export-file)) 'up-to-date) 0 13)
>>> #+BABEL: :var DISP_PACKAGE="seedDisp_0.4-13.**tar.gz"
>>>
>>>
> Have a buffer-level property for all the long lines (sorry if my email
> client wraps these lines):
>
> #+PROPERTY: SVNVERSION (vc-working-revision (buffer-file-name))
> #+PROPERTY: SVNSTATE ( symbol-name (vc-state (or (buffer-file-name)
> org-current-export-file)))
> #+PROPERTY: SVNSTATENUM (if (eq (vc-state (or (buffer-file-name)
> org-current-export-file)) 'up-to-date) 0 13)
> #+PROPERTY: DISP_PACKAGE "seedDisp_0.4-13.tar.gz"
>
>
I think this syntax opens the door for dangerous typos - If you type e.g:

#+PROPERTY: vat x=10

what would this be? it should have been

#+PROPERTY: var x=10

but now? One could allow this syntax in the case that the variable has been
defined before, by using the var syntax:

so

#+PROPERTY: var MAINVERSION=0, SVNVERSION, SVNSTATE, SVNSTATENUM,
DISP_PACKAGE
#+PROPERTY: SVNVERSION (vc-working-revision (buffer-file-name))
#+PROPERTY: SVNSTATE ( symbol-name (vc-state (or (buffer-file-name)
org-current-export-file)))
#+PROPERTY: SVNSTATENUM (if (eq (vc-state (or (buffer-file-name)
org-current-export-file)) 'up-to-date) 0 13)
#+PROPERTY: DISP_PACKAGE "seedDisp_0.4-13.tar.gz"

should be OK, as SVNVERSION is already defined, but

#+PROPERTY: SVNVERSION (vc-working-revision (buffer-file-name))
#+PROPERTY: SVNSTATE ( symbol-name (vc-state (or (buffer-file-name)
org-current-export-file)))
#+PROPERTY: SVNSTATENUM (if (eq (vc-state (or (buffer-file-name)
org-current-export-file)) 'up-to-date) 0 13)
#+PROPERTY: DISP_PACKAGE "seedDisp_0.4-13.tar.gz"
#+PROPERTY: var MAINVERSION=0, SVNVERSION, SVNSTATE, SVNSTATENUM,
DISP_PACKAGE

not, as the variables are only defined later.


But this would not make

#+PROPERTY+:

redundant, but rather enhance it.

Cheers,

Rainer

Cheers,

Rainer



SNIP


> Yours,
> Christian
>



-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax (F):       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

[-- Attachment #2: Type: text/html, Size: 6767 bytes --]

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Christian Moe]

> This all sounds very interesting, but I have problems understanding
> the advantages - possibly because I only had one coffee this morning.

It may not be feasible and the disadvantages may outnumber the 
advantages; we'll see. But having several coffees under my belt 
already, I'll argue my corner. :-)

To recapitulate, I'm proposing that the values of (declared) variables 
for code blocks could be assigned from properties with the same names, 
so that:

:PROPERTIES:
:var: x=1, y=2, z=-3
:END:

could also, and interchangeably, be written:

:PROPERTIES:
:x: 1
:y: 2
:z: -3
:var: x, y, z
:END:

Here setting the `var' property with variable names, but without 
assignments, would declare that the variables are to be passed to the 
src block, and prompt Babel to look for the values in properties with 
the same names.

I think some of the advantages should be clear.


First:
------

It would easily let code blocks collect data from Org entry 
properties, without having to use lisp expressions or first collecting 
the properties in a dynamic block and then referencing the d.b. This 
would be nice particularly when your data is already in 
outline/property form.


A second advantage:
-------------------

It would allow a great deal of flexibility in passing variables 
according to position in the outline hierarchy.

#+BEGIN_EXAMPLE
   * Some default settings
     :PROPERTIES:
     :x: 1
     :y: 2
     :z: -3
     :var: x, y, z
     :END:

   ** For all cases where y=5
      :PROPERTIES:
      :y: 5
      :END:

   *** A case where x=1, y=5, z=-3

   #+begin_src R
     (...)
   #+end_src

   *** A case where x=1, y=5, z=8: no need to specify y again

   #+begin_src R :var z=8
     (...)
   #+end_src

   (z could alternatively have been specified as a property, same as y 
above)
#+END_EXAMPLE

This modular re-use of values from higher up in the outline, on any 
number of levels, should more than compensate for the loss of 
buffer-wide assignments with the #+BABEL header.

With a single :var: property for passing arguments, on the other hand, 
this is not possible. You have to re-assign values to all three 
variables on each level. (Note: Eric's idea for accumulative 
properties, on the other hand, /would/ allow you to do this with a 
single :var: property.)

>
>     #+PROPERTY: SVNVERSION (vc-working-revision (buffer-file-name))
>     #+PROPERTY: SVNSTATE ( symbol-name (vc-state (or
>     (buffer-file-name) org-current-export-file)))
>     #+PROPERTY: SVNSTATENUM (if (eq (vc-state (or (buffer-file-name)
>     org-current-export-file)) 'up-to-date) 0 13)
>     #+PROPERTY: DISP_PACKAGE "seedDisp_0.4-13.tar.gz"
>
>
> I think this syntax opens the door for dangerous typos - If you type e.g:
>
> #+PROPERTY: vat x=10
>
> what would this be? it should have been
>
> #+PROPERTY: var x=10
>
> but now?

Now there would be a :vat: property with the value "x=10". It will not 
be passed to any code block because (as I imagine the scheme) any 
variables to be passed to a code block still need to be /declared/ 
with a :var: property or :var header argument, so it will not conflict 
with any `vat' variable you might have defined in the code. Instead, 
you will notice the typo when your code block results in an error 
message that x is missing, same as now. The result of misspelling var 
under my scheme would be the same as misspelling it now.

> One could allow this syntax in the case that the variable has
> been defined before, by using the var syntax:

To simplify your example, you think this is permissible:

#+PROPERTY: var x, y, z
#+PROPERTY: x 1
#+PROPERTY: y (1+ 1)
#+PROPERTY: z (- 0 3)

but this is not:

#+PROPERTY: x 1
#+PROPERTY: y (1+ 1)
#+PROPERTY: z (- 0 3)
#+PROPERTY: var x, y, z

As I imagine the scheme, it wouldn't matter and the two are 
interchangeable. The `#+PROPERTY: y (1+ 1)' assignment, in and of 
itself, would only create a property :y: with the string value "(1+ 
1)". When Babel began to execute a code block, it would first look up 
the value of the property :var: at point to see what variables to 
pass, and the order of the PROPERTY headers is not important. It would 
then look for the values of the properties :x:, :y: and :z: at point, 
and only then, knowing that these are variables for a code block, 
would it evaluate any lisp expressions in these values.


A third advantage:
------------------

It would provide one way to solve your problem -- very long assignment 
expressions that are difficult to group on a line. It is not 
necessarily the best way to solve that specific problem, compared with 
the various options Eric came up with, such as #+PROPERTY+:.

>
> But this would not make
>
> #+PROPERTY+:
>
> redundant, but rather enhance it.

Possibly; my solution only applies to the :var passed to a code block; 
there may be other property assignments that it would be good to be 
able to split over several lines. Also, I can certainly see the 
attraction of the analogous #+TBLFM+: -- though I'm fine with the 
existing `C-c '' solution for that, and would be equally happy to see 
that solution extended to solve your problem.


Yours,
Christian

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Sebastien Vauban]

Hi all,

Christian Moe wrote:
>> This all sounds very interesting, but I have problems understanding
>> the advantages - possibly because I only had one coffee this morning.
>
> I think some of the advantages should be clear.
>
> A second advantage:
> -------------------
>
> It would allow a great deal of flexibility in passing variables 
> according to position in the outline hierarchy.
>
> #+BEGIN_EXAMPLE
>    * Some default settings
>      :PROPERTIES:
>      :x: 1
>      :y: 2
>      :z: -3
>      :var: x, y, z
>      :END:
>
>    ** For all cases where y=5
>       :PROPERTIES:
>       :y: 5
>       :END:
>
>    *** A case where x=1, y=5, z=-3
>
>    #+begin_src R
>      (...)
>    #+end_src
>
>    *** A case where x=1, y=5, z=8: no need to specify y again
>
>    #+begin_src R :var z=8
>      (...)
>    #+end_src
>
>    (z could alternatively have been specified as a property, same as y 
> above)
> #+END_EXAMPLE
>
> This modular re-use of values from higher up in the outline, on any 
> number of levels, should more than compensate for the loss of 
> buffer-wide assignments with the #+BABEL header.
>
> With a single :var: property for passing arguments, on the other hand, 
> this is not possible. You have to re-assign values to all three 
> variables on each level. (Note: Eric's idea for accumulative 
> properties, on the other hand, /would/ allow you to do this with a 
> single :var: property.)

I think discussing all of this is beneficial and can lead to very interesting
solutions.

But I just have a comment on your second advantage, something that can render
your example inefficient: inheritance is not on by default, and you need to
enable if for *specific properties*.

Make it on by default would be a very bad idea -- just think at examples of
the mails sent through Org-mime: what about setting a Cc or To somewhere and
inheriting that in all the file/subtree/etc. May be scary or inefficient
performance-wise?

Anyway, setting inheritance of properties to on, means you should declare the
behavior for vars x, y and z, ie declaring it 3 times... Except, maybe, if you
say that "var: x, y, z" does that too (then you've two things in one shot --
why not?).

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Christian Moe]

On 10/24/11 2:11 PM, Sebastien Vauban wrote:
(...)
>
> But I just have a comment on your second advantage, something that can render
> your example inefficient: inheritance is not on by default, and you need to
> enable if for *specific properties*.

You can set `org-use-property-inheritance' to t, to make all 
properties inheritable, or you can set it to a list to enable specific 
properties. I suppose you meant that the former would be a bad idea. 
(And it could be, depending on your working habits, file size, outline 
nesting depth and the speed of your machine.)

But you're right, property inheritance is not on by default and I 
forgot to mention that this time around. (I think I did mention it in 
the previous long message where I presented the idea.)

> Make it on by default would be a very bad idea -- just think at examples of
> the mails sent through Org-mime: what about setting a Cc or To somewhere and
> inheriting that in all the file/subtree/etc. May be scary or inefficient
> performance-wise?
>
> Anyway, setting inheritance of properties to on, means you should declare the
> behavior for vars x, y and z, ie declaring it 3 times... Except, maybe, if you
> say that "var: x, y, z" does that too (then you've two things in one shot --
> why not?).

Yes, if my suggestion becomes reality, this could be a useful refinement.

Yours,
Christian

Re: [RFC] Standardized code block keywords

[Darlan Cavalcante Moreira]

Does org have TAB completion in "call lines" for names of blocks that can
be called?  Using "srcname" for blocks of code could make things easier but
if this is not the case then I "name" is just fine.

--
Darlan

At Mon, 24 Oct 2011 08:37:13 +0100,
Eric S Fraga <e.fraga@ucl.ac.uk> wrote:
> 
> Daniel Bausch <DanielBausch@gmx.de> writes:
> 
> > Hi,
> >
> >>          named code blocks [1] -- "source" "srcname" "function"
> >> calling external functions [2] -- "call" "lob"
> >>                 named data [3] -- "tblname" "resname" "results" "data"
> >
> > what about "#+name:" for [1] and [3], and "#+call:" for [2] ?
> >
> > That a table or list contains data is obvious.  The only thing, the additional 
> > line is for, is to "name" it.  That a source block contains source is also 
> > obvious and is already noted by the use of #+begin_src, so why duplicate the 
> > "src"-part?
> >
> > Daniel
> 
> I don't know if I've left it too late to vote on this but...
> 
> I would go for "name" for [1] and [3] and "call" for [2].
> 
> I can, however, see the need for distinguishing between data tables and
> results so could be convinced that "data" and "results" should be used
> for [3].  In any case, I do know that I dislike srcname and tblname...
> 
> -- 
> : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1
> : using Org-mode version 7.7 (release_7.7.452.g767f5)
> 

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Nicolas Goaziou]

Hello,

Christian Moe <mail@christianmoe.com> writes:

> But you're right, property inheritance is not on by default and
> I forgot to mention that this time around. (I think I did mention it
> in the previous long message where I presented the idea.)

AFAIK, Babel has always searched its properties with inheritance on,
independently on user configuration. Thus, it doesn't matter much in
that case.

Regard,

-- 
Nicolas Goaziou

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Darlan Cavalcante Moreira]

I didn't check the list for 3 days and this thread became a little hard to
follow. So, forgive me if I'm "answering" the wrong E-Mail.


I liked Christian's idea of using a single "var" property to tell babel
which regular properties it should use as variables (ignoring any variable
not defined). This would be enough for my use cases.

On the other hand, some way to append values to a property, such as using
some special keyword as I have suggested, could be a better solution in
order to keep consistence if people want this feature for non-babel related
properties.

--
Darlan

At Sat, 22 Oct 2011 09:53:25 -0600,
Eric Schulte wrote:
> 
> Darlan Cavalcante Moreira <darcamo@gmail.com> writes:
> 
> > It's excellent that now babel understands multiple values in the "var"
> > property (I was one of the people that wanted this), but "There Is One More
> > Thing".
> >
> > Would it be feasible to inherit variables from parent sub-trees?
> > Effectively, I'd like to append new values in lower level sub-trees, but
> > AFAIK setting the var property in a sub-tree will still replace the value
> > set in the parent sub-tree.
> >
> 
> Currently every new property specification entirely replaced previous
> specifications with the same name.
> 
> >
> > That is, in the example below the level-2 sub-trees would not have the foo
> > variable passed to babel.
> > * Code with foo
> >   :PROPERTIES:
> >   :var:      foo=1
> >   :END:
> >
> > ** Code only with bar
> >    :PROPERTIES:
> >    :var:      bar=2
> >    :END:
> >    src_block
> > ** Code only with baz
> >    :PROPERTIES:
> >    :var:      baz=3
> >    :END:
> >    src_block
> >
> > Maybe a special keyword, such as "inherit" (or "append") could be used to
> > incorporate variables defined in the parent sub-tree, such that the example
> > would become
> > * Code with foo
> >   :PROPERTIES:
> >   :var:      foo=1
> >   :END:
> >
> > ** Code with foo and bar
> >    :PROPERTIES:
> >    :var:      bar=2, inherit
> >    :END:
> >    src_block
> > ** Code with foo and baz
> >    :PROPERTIES:
> >    :var:      baz=3, inherit
> >    :END:
> >    src_block
> >
> > This should not affect global variables and "inherit" would inherit
> > variables defined only in the parent sub-tree (unless it also contains the
> > inherit keyword).
> >
> > As a use case scenario, suppose I need to perform simulations for a few
> > different scenarios, each with small variations. This would allow me to
> > define common variables for a scenario in a higher level sub-tree and more
> > specific variables in the lower level sub-trees.
> >
> 
> This sounds somewhat similar to my suggestion in reply to Rainer's
> email.
> 
> Best -- Eric
> 
> >
> > --
> > Darlan Cavalcante
> >
> >
> > At Fri, 21 Oct 2011 22:24:25 +0200,
> > Christian Moe <mail@christianmoe.com> wrote:
> >> 
> >> Hi,
> >> 
> >> Yes, that works nicely, and should solve Rainer's problem.
> >> I haven't been able to think of anything else that can't be handled by 
> >> properties.
> >> 
> >> And I do think it's a good idea to winnow down the syntax a bit, even 
> >> if things break. I just like to grumble.
> >> :-)
> >> 
> >> Yours,
> >> Christian
> >> 
> >> On 10/21/11 7:37 PM, Eric Schulte wrote:
> >> > Nice idea.  This same issue with "var" arose when we first started
> >> > allowing header arguments to be specified inside subtree properties.
> >> > I've just implemented your suggestion so the following are now possible.
> >> >
> >> > #+PROPERTY: var foo=1, bar=2
> >> > #+PROPERTY: cache yes
> >> >
> >> > #+begin_src emacs-lisp
> >> >    (+ foo bar)
> >> > #+end_src
> >> >
> >> > #+results[be32e67491d4e92f75769aebe423c20ca01626fe]:
> >> > : 3
> >> >
> >> > and
> >> >
> >> > #+begin_src emacs-lisp :var foo="this", bar="that"
> >> >    (concat foo " " bar)
> >> > #+end_src
> >> >
> >> > #+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]:
> >> > : this that
> >> >
> >> > Thanks for the suggestion and I hope the above is a sufficient
> >> > replacement for the now-missing #+BABEL: syntax.
> >> >
> >> > Cheers -- Eric
> >> 
> >> 
> 
> -- 
> Eric Schulte
> http://cs.unm.edu/~eschulte/

Re: [RFC] Standardized code block keywords

[Eric Schulte]

"Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:

> Hi Daniel,
>
> Daniel Bausch wrote:
>>>          named code blocks [1] -- "source" "srcname" "function"
>>> calling external functions [2] -- "call" "lob"
>>>                 named data [3] -- "tblname" "resname" "results" "data"
>>
>> what about "#+name:" for [1] and [3], and "#+call:" for [2] ?
>>
>> That a table or list contains data is obvious.  The only thing, the additional 
>> line is for, is to "name" it.
>
> As Eric showed us, this is not always to name it... If the table is the
> results of an unamed block, you will have #+name: followed by no name!
>
> #+name:
> | line 1 | data1 |
> | line 2 | data2 |
>
> what I also find quite disturbing.
>

I also find this to be disconcerting. -- Eric

>
> Best regards,
>   Seb

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [RFC] Standardized code block keywords

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 5353 bytes --]

On Fri, Oct 21, 2011 at 6:24 PM, Eric Schulte <schulte.eric@gmail.com>wrote:

> > Just to make it as easy as possible for everyone....
> > Might it be possible to introduce a small flags like "obsolete" and
> > "stable" (standard)
> > Old functions, old syntax, etc., might move first to obsolete before
> > completely removed...
> > We could open an older file and if it isn't working, we could try
> >
> > #+PROPERTY: babel-function-set obsolete
> >
>
> I think that making use of such a feature is almost as onerous as
> changing to the new terms (which is a simple search replace, in fact
> once terms are selected I'll happily share a function on list which can
> be used to convert all old terms in existing Org-mode files).
>

The problem are not every-day users, but if one is not using org-mode not
using for some time, it might be difficult to figure out what has changed -
also, I wou't remember in three years time, that these things have changed,
and run into problems when trying to open an old org-file (in the case of
literae programming not unlikely).

But I also see your point - Eric.

Would it be an option to include a function which checks if these files do
include the old / deprecated keywords, and inform the user? This function
could even, in this case here, suggest to do the replacing. This function
could be over time extended, whenever in-compatible changes become necessary
- it would be a kind of an org-to-org converter or org-version-checker?


Concerning voting:

Definitely #+call.

I don't like the #+srcname, because most of my blocks are not named, and it
would look weired (I have never used #+tblname but if I also think that that
looks weired if there is no name coming afterwards...).

I would vote for:

#+src

#+object
sounds more "modern" then data.

Just an idea ():

#+object_begin var
  x = 1
  y = 2
#+end

could possible be used for as an alternative for :var ?


And the #+results should stay for generated data to keep them separate (will
/ can be programmatically changed)

Cheers,

Rainer


>
> >
> > if it works, we have to modify the code, because obviously the code
> > requires changed to be compatible in the future. However, just for the
> > moment it is still working. This would give people more time to change
> > there code accordingly. As murphy law tells us one will notice that
> > the particular file is broken exact 5 minutes before the meeting with
> > your boss standing behind you yelling.... print it, print it  ;)
> >
> > I know git would be perfect to keep the code base frozen for a certain
> > syntax. However, babel is bundled with org-mode which is bundled with
> > Emacs. Thus, it might be very difficult to tell people they have to
> > use org-babel from git with the tag [org-babel_XX] if they want to use
> > there old style files.  AFAIK org-babel does not even come with a own
> > version numbering, right?
> >
> > Alternatively, keep the syntax a little bit longer as it is and create
> > warning messages to point users to future changes (not sure how much
> > time left for emacs24)
> > "Warning: #+lob: in line XX is obsolete, please use #+call: in the
> > future. (manual-link)"
> >
> > To make is short, is is possible to introduce changes "slowly"
> >
>
> I fear this would simply serve to introduce more complexity and
> confusion.
>
>
> >
> > As for voting:
> > [1]
> > #+function: would be what I would expect from other programming
> > languages. Where an unnamed source code block would be something like
> > a lambda function.
> > However, "function" as a term is heavily used in many target languages
> > too. This makes parsing, reading and discussing a bit difficult. ("I
> > called the function foo", "Wait, do you call the org-mode function
> > foo, or the python function foo?")
> > Thus, I vote for #+srcname similar to #+tblname to make sure about the
> > difference between org-babel and the target languages.
> >
> > [2]
> > #+call:, simply because I never can remember "lob" and the acronym is
> > something difficult for newbies.
> >
>
> noted, thanks
>
> >
> > [3]
> > I tend to  #+results: because it fits more to the entire babel syntax.
> > However, earlier on the mailing list people were pointing out that one
> > is going to change "results" for a unknown source block (that was the
> > reason "data" was introduced).... and I think this is a valid
> > argument. Maybe "data" and "results" should be both valid if only to
> > pleasure human thinking. However, if I understood correctly, maybe
> > data could be changed to be more some type of constant? That is,
> > #+data: foo can not be changed by a source code block named foo
> > (because it isn't a "result" but "data") but only by human (as a
> > "data" input). Does this make sense?
> >
>
> yes, I'll mark you down for "data and results", which I think is a
> perfectly fine option.
>
> Thanks for sharing -- Eric
>
> >
> > Totti
> >
>
> --
> 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:      Rainer@krugs.de

Skype:      RMkrug

[-- Attachment #2: Type: text/html, Size: 6877 bytes --]

Re: [RFC] Standardized code block keywords

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 7269 bytes --]

On Tue, Oct 25, 2011 at 8:52 AM, Rainer M Krug <r.m.krug@gmail.com> wrote:

>
>
> On Fri, Oct 21, 2011 at 7:37 PM, Sebastien Vauban <
> wxhgmqzgwmuf@spammotel.com> wrote:
>
>> Hi Eric,
>>
>> Eric Schulte wrote:
>> >> Now, between "srcname" and "source": I'm used to whatever my Yasnippet
>> is
>> >> entering for me. That's currently "srcname". I don't have a strong
>> opinion,
>> >> though, to choose one over the other, except that I like Nick's
>> argument with
>> >> the table analogy.
>> >>
>> >>> I agree on [2] "call".
>> >>
>> >> I clearly agree on "call" as well.
>> >
>> > noted, thanks
>>
>> I think you'll get unanimity on that one.
>>
>> >> Here, I'd like to ask: what about "sbe"?  In my own understanding, it's
>> a
>> >> call, absolutely similar to "call". Is there a technical reason to be
>> forced
>> >> to differentiate both?  If no, can we use "call" as well instead of
>> "sbe"?
>> >
>> > The only difference is that sbe is a function name, and to name a
>> > function call (a function which will take up that term in the entire
>> > Emacs-lisp namespace across all applications) seems somewhat pushy.
>>
>> OK. Point understood. May I suggest to try to find a better name, still?
>>  Once
>> we're at it, modifying one extra line in the documentation won't hurt.
>>
>> I don't know what others find, but I've never understood what it meant.
>> OK,
>> now (since yesterday, in fact), I know it means "source block evaluation",
>> but
>> that's not really intuitive.
>>
>> I'd opt for "ob-call" (package name + "call") or something like that, if I
>> could choose.
>>
>> >>> I'm confused by [3] so I will say nothing for now, except to ask some
>> >>> questions: are we talking about what a human would use to label a
>> piece of
>> >>> data for consumption by a block (including perhaps the future
>> possibilities
>> >>> of lists and paragraphs that Tom brought up)? what babel would use to
>> label
>> >>> a results block (possibly so that it could be consumed by another
>> block in a
>> >>> chain)? both? would that mean that #+tblname would go the way of the
>> dodo
>> >>> and that tables would be labelled with #+data (or #+object or whatever
>> else
>> >>> we come up with)?
>> >>
>> >> For point 3, Eric, I guess that whichever term is chosen, that does not
>> mean
>> >> that "results" will change (I mean: when it's a result of a block
>> execution)?
>>
>> I was expecting you'd always keep "results" for auto-inserted results
>> (after a
>> code block evaluation). But it makes sense to prefer the one term that
>> will
>> win.
>>
>
> I would definitely keep #+results as this marks it as an *output* which can
> change during the next evaluation, and not an input, which has to be
> modified by hand. I would actually go so far and say that #+results *can be*
> src or object (using these terms), but is in itself *not* identifying
> anything, apart from "this is the result of an evaluation". So:
>
> #+results
> #+object_begin
>  .
>  .
>  .
> #+end
>
> would be the result of an evaluation.
>
> One could even, for clarities sake, say that
>
> #+object
>
> if no #+results is in the line before,
>
> is a synonym for
>
> #+input (or #+constant)
> #+object_begin
>  .
>  .
>  .
> #+end
>
> Cheers,
>
> Rainer
>
>
>> > I would be happy for results to change to data or tblname (if a table)
>> > or whatever else is selected.
>>
>> OK, clear.
>>
>> >> In other words, if we choose for "object", we still will have the
>> possibility
>> >> to use "results" (automatically generated) and "object" to refer to
>> something
>> >> we want to use in another call?
>> >>
>> >>>>>                 named data [3] -- "tblname" "resname" "results"
>> "data"
>> >>
>> >> I don't specifically like "resname".
>> >>
>> >> I would keep "results" for automatically generated "results".
>> >>
>> >> I do like "data", but can learn to like "object" as a more generic
>> term,
>> >> future-proof for coming extensions.
>> >
>> > I'll mark you down as undecided for this term. :)
>>
>> Yep!  I'm open to any suggestion you'll make.
>>
>> >> Last remark: we could get one step further and wonder if it wouldn't be
>> good
>> >> to impose a single way to pass variables? We currently have two
>> different
>> >> mechanisms:
>> >>
>> >>     #+srcname: convert-date-to-French-format
>> >>     #+begin_src sql :var column=""
>> >>     CONVERT(varchar(10), $column, 103) AS $column
>> >>     #+end_src
>> >>
>> >> and
>> >>
>> >>     #+srcname: convert-date-to-French-format(column="")
>> >>     #+begin_src sql
>> >>     CONVERT(varchar(10), $column, 103) AS $column
>> >>     #+end_src
>> >>
>> >> I guess that the first one is easier if we want to construct complex
>> variable
>> >> values (which call Emacs Lisp code or such), but...
>> >
>> > I don't feel that this example causes as much confusion, but if I'm
>> > wrong I am open to change on this front.  Although the only possible
>> > change here would be to remove the second option as the first method of
>> > specifying variables is central to code block management.
>>
>> Just that I remember both syntaxes weren't handled the same way for error
>> reporting (remember, when there is no default value: in one case, you can
>> get
>> the name of the faulty block; in the other, not), and that makes me think
>> is
>> not as simple as an alias. Hence, your Babel code is or can become
>> different
>> just because there are different alternatives to write certain things
>> down.
>>
>> Then, as a user, I always wonder what's the best one?  "For a good error
>> reporting (with the name of the code block being outputted), which one do
>> I
>> have to use?" and such questions...
>>
>> If we only have one way, we can be sure everybody experiences the same
>> things
>> with the same semantical input.
>>
>> Another point, that may or may not have much to do with this, is that I
>> don't
>> have anymore the source name exported in HTML -- dunno when it
>> disappeared,
>> though. I remember that, at some point, it was due to having, or not, a
>> default value (at the time, having no default value was still allowed),
>> but
>> now, even with the default values for every var, I miss those names in the
>> HTML (for literate programming support, it is quite useful to be able to
>> see
>> the name of the block along with the code).
>>
>> I repeat myself, but thanks, once again, for tackling this naming
>> "problem".
>>
>> 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:      Rainer@krugs.de
>
> Skype:      RMkrug
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax (F):       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

[-- Attachment #2: Type: text/html, Size: 9790 bytes --]

Re: [RFC] Standardized code block keywords

[Daniel Bausch]

Am Dienstag 25 Oktober 2011, 03:30:46 schrieb Eric Schulte:
> "Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:
> > Hi Daniel,
> > 
> > Daniel Bausch wrote:
> >>>          named code blocks [1] -- "source" "srcname" "function"
> >>> 
> >>> calling external functions [2] -- "call" "lob"
> >>> 
> >>>                 named data [3] -- "tblname" "resname" "results" "data"
> >> 
> >> what about "#+name:" for [1] and [3], and "#+call:" for [2] ?
> >> 
> >> That a table or list contains data is obvious.  The only thing, the
> >> additional line is for, is to "name" it.
> > 
> > As Eric showed us, this is not always to name it... If the table is the
> > results of an unamed block, you will have #+name: followed by no name!
> > 
> > #+name:
> > | line 1 | data1 |
> > | line 2 | data2 |
> > 
> > what I also find quite disturbing.
> 
> I also find this to be disconcerting. -- Eric
> 
> > Best regards,
> > 
> >   Seb

Then maybe #+results for (anonymous) results only, but #+name for anything 
else from [1] and [3].  Wasn't there a concept of linking a results block to 
its originiating source block by some id and we need a place to put the 
checksum in.  So I see some arguments for treating results special.  But for 
the others I do not see pressing arguments against a common "name" at the 
moment.  However, I'd like to ask, what happens, if one refers to a name of a 
source block where data is expected, does it then refer to the results 
produced by that source block?  How are such situations handeled at the 
moment?  In other words: is there any type checking?  Type checking could be 
facilitated by using different words, although I think that is not neccessary, 
because there are other means to distinguish the type of a block (look at the 
next line in the buffer).

Daniel

Re: [RFC] Standardized code block keywords

[Jambunathan K]

> #+object_begin var
> x = 1
> y = 2
> #+end

I was thinking on similar lines. This together with Nicolas's suggestion
of "one name" will be wonderful.

I think it is easier to explain what I think by means of an example. In
case of lisp, the SAME variable name could either act as a function or a
variable. The way the VARIABLE NAME is INTERPRETED, DEPENDS ON THE
CONTEXT in which it needs to be interpreted. Similarly a VAR could be
EVALLED or just be a QUOTED SYMBOL.

Coming back to the above example -

If the HANDLE for the above block (whatever you call it), appears as a
PARAM OF BABEL CALL it would be interpreted as a param list. 

Think `apply' and `&rest args' in the elisp world.

Another near equivalent would be COERCING or CASTING. In abstract terms,
the above block could be treated as a TABLE. In some sense, a LIST or a
LIST OF LIST could be coerced in to a TABLE.

I consider babel to be a VM and an execution environment - i.e., as a
scripting environment for Org. So definitely we can borrow ideas from
the existing languages and extend it.

In summary, what I am saying is EVERYTHING IS A BLOB. The way a BLOB is
INTERPRETED depends on the CONTEXT in which interpretation happens. A
BLOB in and of itself is but JUST A BLOB and has NO INHERENT meaning.

I don't use babel myself so I may not be using the right set of
words. Also it is not my intention to hijack the thread.

Jambunathan K.

Re: [RFC] Standardized code block keywords

[Sebastien Vauban]

Hi Daniel,

Daniel Bausch wrote:
> Am Dienstag 25 Oktober 2011, 03:30:46 schrieb Eric Schulte:
>> "Sebastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>> > Daniel Bausch wrote:
>> >>>          named code blocks [1] -- "source" "srcname" "function"
>>>>> 
>>>>> calling external functions [2] -- "call" "lob"
>>>>> 
>>>>>                 named data [3] -- "tblname" "resname" "results" "data"
>>>> 
>>>> what about "#+name:" for [1] and [3], and "#+call:" for [2] ?
>>>> 
>>>> That a table or list contains data is obvious.  The only thing, the
>>>> additional line is for, is to "name" it.
>>> 
>>> As Eric showed us, this is not always to name it... If the table is the
>>> results of an unamed block, you will have #+name: followed by no name!
>>> 
>>> #+name:
>>> | line 1 | data1 |
>>> | line 2 | data2 |
>>> 
>>> what I also find quite disturbing.
>> 
>> I also find this to be disconcerting. -- Eric
>
> Then maybe #+results for (anonymous) results only, but #+name for anything
> else from [1] and [3].

Just wanted to say I like the idea of keeping "results" for (at least) output
of an anonymous call.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [RFC] Standardized code block keywords

[Sebastien Vauban]

Hi Rainer,

Rainer M Krug wrote:
> On Fri, Oct 21, 2011 at 6:24 PM, Eric Schulte <schulte.eric-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>wrote:
>>> Just to make it as easy as possible for everyone....
>>> Might it be possible to introduce a small flags like "obsolete" and
>>> "stable" (standard)
>>> Old functions, old syntax, etc., might move first to obsolete before
>>> completely removed...
>>> We could open an older file and if it isn't working, we could try
>>>
>>> #+PROPERTY: babel-function-set obsolete
>>
>> I think that making use of such a feature is almost as onerous as changing
>> to the new terms (which is a simple search replace, in fact once terms are
>> selected I'll happily share a function on list which can be used to convert
>> all old terms in existing Org-mode files).
>
> The problem are not every-day users, but if one is not using org-mode not
> using for some time, it might be difficult to figure out what has changed -
> also, I wou't remember in three years time, that these things have changed,
> and run into problems when trying to open an old org-file (in the case of
> literae programming not unlikely).
>
> But I also see your point - Eric.

And the problem is, someday, you will have to remove such functionality
(allowing a smooth transition, thanks to declaring to use an "obsolete"
feature set). So, IMHO, better do it now, once for all...

... if you have:

> a function which checks if these files do include the old / deprecated
> keywords, and inform the user? 

See my modified version of Eric's function:

#+begin_src emacs-lisp
  ;; warn about deprecated feature from version 7.7
  (add-hook 'org-mode-hook
            (lambda ()
              (save-excursion
                (goto-char (point-min))
                (when (re-search-forward (org-make-options-regexp
                                          '("BABEL")) nil t)
                  (display-warning 'org-babel
                                   (format "This file contains a \"#+BABEL:\" line.")
                                   :warning)))))
#+end_src

My changes:

- warning in its own window, to be sure to see it (because it's soo easy for
  the message in the echo area to be overwritten by others, if you have many
  hooks doing many things);

- no error when match not found.

> This function could even, in this case here, suggest to do the replacing.
> This function could be over time extended, whenever in-compatible changes
> become necessary - it would be a kind of an org-to-org converter or
> org-version-checker?

See this draft:

#+begin_src emacs-lisp
  (defun my/org-propertyze-babel-line ()
    "Play me as many times as needed..."
    (interactive)
    ;; (goto-char (point-min))
    ;; (search-forward "#+BABEL:")
    (search-forward-regexp ":")
    (delete-backward-char 2)
    (insert "\n#+PROPERTY:  "))
#+end_src

To be used, in its current state, with point placed just after the "#+BABEL:"
keyword.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Sebastien Vauban]

Hi Eric,

Eric Schulte wrote:
>> #+BABEL: :var SVNVERSION=(vc-working-revision (buffer-file-name))
>> #+BABEL: :var SVNSTATE=( symbol-name (vc-state (or (buffer-file-name) org-current-export-file)))
>> #+BABEL: :var SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13)
>>
>> which would look horrible in one line and a nightmare to edit.
>
> I can think of three options for how to handle this situation.
>
> 1. If it turns out to be possible/desirable my preferred solution here
>    would be to add general property support for appending values to
>    properties when properties are over specified rather than simply
>    replacing the value.  Perhaps this could be done with a variable like
>    org-accumulating-properties which could hold a list of those
>    properties which should accumulate values rather than overwriting
>    them.
>
> 2. Adding a "#+PROPERTY:" line authoring helper similar to the table
>    formula helper making it more natural to edit such long property
>    lines.
>
> 3. It may be possible to add syntax for extending #+PROPERTY:
>    specifications across multiple lines, something like
>
>    #+PROPERTY: SVNVERSION=(vc-working-revision (buffer-file-name)),
>    #+PROPERTY+: SVNSTATE=( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))),
>    #+PROPERTY+: SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13),
>
>    FWIW I would like to have a similar extender for #+TBLFM: lines.
>    Actually this choice may be my preferred solution.
>
> What do you think?

I think that makes sense.

While thinking about all of this, and working in real-life documents, I just
came back to a suggestion which I made some time ago. It goes about this
enhancement:

    Would it be possible to specify "buffer-wide language specific" header
    arguments?

That is, be able to say:

    "In this document, I want to:
    - tangle all my .sql chunks, but no other;
    - eval all the elisp chunks with query, but no other."

Something we could write quite easily along the lines:

    #+PROPERTY:               tangle no
    #+PROPERTY:               eval never
    #+PROPERTY[SQL]:          tangle yes
    #+PROPERTY[EMACS-LISP]:   eval query

    (the syntax used here is just a draft sample!)

What do you think about this feature? If you feel it can be something
interesting to have, this is surely to incorporate in the current syntax
debate. If not... never mind.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 3531 bytes --]

On Tue, Oct 25, 2011 at 11:35 AM, Sebastien Vauban <
wxhgmqzgwmuf@spammotel.com> wrote:

> Hi Eric,
>
> Eric Schulte wrote:
> >> #+BABEL: :var SVNVERSION=(vc-working-revision (buffer-file-name))
> >> #+BABEL: :var SVNSTATE=( symbol-name (vc-state (or (buffer-file-name)
> org-current-export-file)))
> >> #+BABEL: :var SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name)
> org-current-export-file)) 'up-to-date) 0 13)
> >>
> >> which would look horrible in one line and a nightmare to edit.
> >
> > I can think of three options for how to handle this situation.
> >
> > 1. If it turns out to be possible/desirable my preferred solution here
> >    would be to add general property support for appending values to
> >    properties when properties are over specified rather than simply
> >    replacing the value.  Perhaps this could be done with a variable like
> >    org-accumulating-properties which could hold a list of those
> >    properties which should accumulate values rather than overwriting
> >    them.
> >
> > 2. Adding a "#+PROPERTY:" line authoring helper similar to the table
> >    formula helper making it more natural to edit such long property
> >    lines.
> >
> > 3. It may be possible to add syntax for extending #+PROPERTY:
> >    specifications across multiple lines, something like
> >
> >    #+PROPERTY: SVNVERSION=(vc-working-revision (buffer-file-name)),
> >    #+PROPERTY+: SVNSTATE=( symbol-name (vc-state (or (buffer-file-name)
> org-current-export-file))),
> >    #+PROPERTY+: SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name)
> org-current-export-file)) 'up-to-date) 0 13),
> >
> >    FWIW I would like to have a similar extender for #+TBLFM: lines.
> >    Actually this choice may be my preferred solution.
> >
> > What do you think?
>
> I think that makes sense.
>
> While thinking about all of this, and working in real-life documents, I
> just
> came back to a suggestion which I made some time ago. It goes about this
> enhancement:
>
>    Would it be possible to specify "buffer-wide language specific" header
>    arguments?
>
> That is, be able to say:
>
>    "In this document, I want to:
>    - tangle all my .sql chunks, but no other;
>    - eval all the elisp chunks with query, but no other."
>
> Something we could write quite easily along the lines:
>
>    #+PROPERTY:               tangle no
>    #+PROPERTY:               eval never
>    #+PROPERTY[SQL]:          tangle yes
>    #+PROPERTY[EMACS-LISP]:   eval query
>
>    (the syntax used here is just a draft sample!)
>
> What do you think about this feature? If you feel it can be something
> interesting to have, this is surely to incorporate in the current syntax
> debate. If not... never mind.
>

I am not Eric, but I think that would be a good idea. Bu there needs to be a
way of specifying more then one property, either by #+PROPERTY+: or by any
other way -I acually luike the #+PROPERTY+: .
Thinking about it, it should be possible without the +:

#+PROPERTY[R]: tangle no
#+PROPERTY[R]: export both

The more I see it, the more I like it - also the []

Cheers,

Rainer


> Best regards,
>  Seb
>
> --
> Sebastien Vauban
>
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax (F):       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

[-- Attachment #2: Type: text/html, Size: 4642 bytes --]

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Sebastien Vauban]

Hi Rainer,

Rainer M Krug wrote:
>> While thinking about all of this, and working in real-life documents, I
>> just
>> came back to a suggestion which I made some time ago. It goes about this
>> enhancement:
>>
>>    Would it be possible to specify "buffer-wide language specific" header
>>    arguments?
>>
>> That is, be able to say:
>>
>>    "In this document, I want to:
>>    - tangle all my .sql chunks, but no other;
>>    - eval all the elisp chunks with query, but no other."
>>
>> Something we could write quite easily along the lines:
>>
>>    #+PROPERTY:               tangle no
>>    #+PROPERTY:               eval never
>>    #+PROPERTY[SQL]:          tangle yes
>>    #+PROPERTY[EMACS-LISP]:   eval query
>>
>>    (the syntax used here is just a draft sample!)
>>
>> What do you think about this feature? If you feel it can be something
>> interesting to have, this is surely to incorporate in the current syntax
>> debate. If not... never mind.
>
> I am not Eric, but I think that would be a good idea.

Thanks for your comments.

> Bu there needs to be a way of specifying more then one property, either
> by #+PROPERTY+: or by any other way -I acually luike the #+PROPERTY+: .
> Thinking about it, it should be possible without the +:
>
> #+PROPERTY[R]: tangle no
> #+PROPERTY[R]: export both

Yes, no need for a "+" here, as the lines do target different properties (in
this case, "tangle" and "export").

> The more I see it, the more I like it - also the []

In fact, the lines without any language specification would be, at least
semantically, equivalent to something like this:

      #+PROPERTY[*]:            tangle no
      #+PROPERTY[*]:            eval never

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 3147 bytes --]

On Tue, Oct 25, 2011 at 12:31 PM, Sebastien Vauban <
wxhgmqzgwmuf@spammotel.com> wrote:

> Hi Rainer,
>
> Rainer M Krug wrote:
> >> While thinking about all of this, and working in real-life documents, I
> >> just
> >> came back to a suggestion which I made some time ago. It goes about this
> >> enhancement:
> >>
> >>    Would it be possible to specify "buffer-wide language specific"
> header
> >>    arguments?
> >>
> >> That is, be able to say:
> >>
> >>    "In this document, I want to:
> >>    - tangle all my .sql chunks, but no other;
> >>    - eval all the elisp chunks with query, but no other."
> >>
> >> Something we could write quite easily along the lines:
> >>
> >>    #+PROPERTY:               tangle no
> >>    #+PROPERTY:               eval never
> >>    #+PROPERTY[SQL]:          tangle yes
> >>    #+PROPERTY[EMACS-LISP]:   eval query
> >>
> >>    (the syntax used here is just a draft sample!)
> >>
> >> What do you think about this feature? If you feel it can be something
> >> interesting to have, this is surely to incorporate in the current syntax
> >> debate. If not... never mind.
> >
> > I am not Eric, but I think that would be a good idea.
>
> Thanks for your comments.
>
> > Bu there needs to be a way of specifying more then one property, either
> > by #+PROPERTY+: or by any other way -I acually luike the #+PROPERTY+: .
> > Thinking about it, it should be possible without the +:
> >
> > #+PROPERTY[R]: tangle no
> > #+PROPERTY[R]: export both
>
> Yes, no need for a "+" here, as the lines do target different properties
> (in
> this case, "tangle" and "export").
>
> > The more I see it, the more I like it - also the []
>
> In fact, the lines without any language specification would be, at least
> semantically, equivalent to something like this:
>
>      #+PROPERTY[*]:            tangle no
>      #+PROPERTY[*]:            eval never
>

So

#+PROPERTY followed by square brackets, means properties for source blocks
of a given language, and [*] is the default and can be omitted.

Two ideas: [R,sh], i.e. specifying a list of languages in the brackets could
be useful, as well as wildcards like [dit*]? The latter less usefull, but
for consistency?

Additionally: it would be nice, if one could define a set of properties, and
then recall them for certain blocks.

e.g:

#+PROPERTY[R:set1]: tangle no
#+PROPERTY[R:set1]: eval never

#+PROPERTY[R:set2]: tangle yes
#+PROPERTY[R:set2]: export both

#+src_begin R :set set1
  cat(1)
#+end

would have the first set of properties (tangle no and eval never), where

#+src_begin R :set set2
  cat(1)
#+end

would have the second set of properties (tangle no and eval never)

Might be a good addition?

Cheers,


Rainer


> Best regards,
>  Seb
>
> --
> Sebastien Vauban
>
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax (F):       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

[-- Attachment #2: Type: text/html, Size: 4327 bytes --]

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Eric Schulte]

> I think that makes sense.
>
> While thinking about all of this, and working in real-life documents, I just
> came back to a suggestion which I made some time ago. It goes about this
> enhancement:
>
>     Would it be possible to specify "buffer-wide language specific" header
>     arguments?
>

Yes, this is already possible.  You can customize the
org-babel-default-header-args:lang variable (where "lang" is the source
name) as a file local variable.

>
> That is, be able to say:
>
>     "In this document, I want to:
>     - tangle all my .sql chunks, but no other;
>     - eval all the elisp chunks with query, but no other."
>
> Something we could write quite easily along the lines:
>
>     #+PROPERTY:               tangle no
>     #+PROPERTY:               eval never
>     #+PROPERTY[SQL]:          tangle yes
>     #+PROPERTY[EMACS-LISP]:   eval query
>
>     (the syntax used here is just a draft sample!)
>

I do not think we can customize the PROPERTY syntax as is exists outside
of Babel.  The goal here was to piggy-back on top of rather than co-opt
regular Org-mode syntax.

Best -- Eric

>
> What do you think about this feature? If you feel it can be something
> interesting to have, this is surely to incorporate in the current syntax
> debate. If not... never mind.
>
> Best regards,
>   Seb

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [RFC] Standardized code block keywords

[Eric Schulte]

>
> Then maybe #+results for (anonymous) results only, but #+name for anything 
> else from [1] and [3].

This seems like a reasonable approach.

> Wasn't there a concept of linking a results block to its originiating
> source block by some id and we need a place to put the checksum in.

Not that I recall.

> 
> So I see some arguments for treating results special.  But for the
> others I do not see pressing arguments against a common "name" at the
> moment.  However, I'd like to ask, what happens, if one refers to a
> name of a source block where data is expected, does it then refer to
> the results produced by that source block?  How are such situations
> handeled at the moment?

Try it out, but be ready to press C-g, because I would guess that it
results in an infinite loop.

> In other words: is there any type checking?  Type checking could be
> facilitated by using different words, although I think that is not
> neccessary, because there are other means to distinguish the type of a
> block (look at the next line in the buffer).
>

No, there is no type checking in Babel, and the mere thought of
implementing such a features leaves me exhausted.  I think it is safe to
allow users to shoot themselves in the foot if they so please.

Cheers -- Eric

>
> Daniel

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [RFC] Standardized code block keywords

[Eric Schulte]

Alright,

I've tallied up the results and we have the following (with full voting
information below [1]).

Call lines
| call | 13 |

It seems unanimous that remote code block calls should use the #+call:
syntax moving forward.

Data and result names
| (name results)   | 3 |
| name             | 2 |
| (data results)   | 2 |
| (object results) | 1 |
| data             | 1 |
| object           | 1 |

The Data and result name lines were less straightforward, but I think
the best solution which also seems to be the majority opinion will be to
allow #+name: lines to be used to name results, and in the case of
results of un-named code blocks a #+results: line will be used.

It will also be necessary to allow usage of #+tblname: for as long as
this syntax is used to name tables for Org-mode spreadsheet formulas.

Code block names
| srcname | 5 |
| name    | 4 |
| source  | 3 |
| src     | 1 |

Surprisingly (to me) srcname is the winner here, but luckily I haven't
yet voted, and although I would have though #+source: would have been
the winner I like the simplicity of using #+name: for named code blocks
as well as named data.  So I'll vote for #+name: here making it a tie,
and I'll also take tie-breaking powers upon myself giving #+name: the
win.

I hope to put together an implementation of this change soon.

Cheers -- Eric

Footnotes: 
[1]  ** eliminate synonyms

#+tblname: code-block-names
| source  | dye       |
| srcname | dokos     |
| srcname | moe       |
| srcname | vauban    |
| srcname | wagner    |
| name    | goaziou   |
| srcname | thorsten  |
| source  | rosenfeld |
| name    | bausch    |
| source  | malone    |
| name    | moreira   |
| name    | fraga     |
| src     | krug      |

#+tblname: call-lines
| call | dye       |
| call | dokos     |
| call | moe       |
| call | vauban    |
| call | wagner    |
| call | goaziou   |
| call | thorsten  |
| call | rosenfeld |
| call | bausch    |
| call | malone    |
| call | moreira   |
| call | fraga     |
| call | krug      |

#+tblname: data-names
| object           | dye       |
| (data results)   | wagner    |
| name             | goaziou   |
| (data results)   | rosenfeld |
| (name results)   | bausch    |
| data             | malone    |
| name             | moreira   |
| (name results)   | fraga     |
| (object results) | krug      |
| (name results)   | vauban    |

#+begin_src emacs-lisp :var data=call-lines
  (mapcar (lambda (el) (list (car el) (cdr el)))
          (reduce (lambda (acc vote)
                    (cons (cons vote (+ 1 (or (cdr (assoc vote acc)) 0)))
                          (remove-if (lambda (pair) (equal (car pair) vote)) acc)))
                  (mapcar #'car data) :initial-value ()))
#+end_src

Call lines
| call | 13 |

Data and result names
| (name results)   | 3 |
| name             | 2 |
| (data results)   | 2 |
| (object results) | 1 |
| data             | 1 |
| object           | 1 |

Code block names
| srcname | 5 |
| name    | 4 |
| source  | 3 |
| src     | 1 |


-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [RFC] Standardized code block keywords

[Christian Moe]

> Surprisingly (to me) srcname is the winner here, but luckily I haven't
> yet voted, and although I would have though #+source: would have been
> the winner I like the simplicity of using #+name: for named code blocks
> as well as named data.

Ditto -- it just wasn't on the table yet when I cast my vote.

Christian

Re: [RFC] Standardized code block keywords

[Nick Dokos]

Eric Schulte <schulte.eric@gmail.com> wrote:

> Surprisingly (to me) srcname is the winner here, but luckily I haven't
> yet voted, and although I would have though #+source: would have been
> the winner I like the simplicity of using #+name: for named code blocks
> as well as named data.  So I'll vote for #+name: here making it a tie,
> and I'll also take tie-breaking powers upon myself giving #+name: the
> win.
> 

This is going to cost you, Schulte! It's not going to go down that easily.
I'll call the FTC, the FCC, the SCOTUS, the POTUS, the NYT, the BDFL, the
NFL and the MLB: an outrage I tell you! An affront to the democratic rules
some of us cherish! We'll fight to the death! Who's with me?




Nobody?




Dang - I'll go back to sleep then.

Re: [RFC] Standardized code block keywords

[Martyn Jago]

Nick Dokos <nicholas.dokos@hp.com> writes:

> Eric Schulte <schulte.eric@gmail.com> wrote:
>
>> Surprisingly (to me) srcname is the winner here, but luckily I haven't
>> yet voted, and although I would have though #+source: would have been
>> the winner I like the simplicity of using #+name: for named code blocks
>> as well as named data.  So I'll vote for #+name: here making it a tie,
>> and I'll also take tie-breaking powers upon myself giving #+name: the
>> win.
>> 
>
> This is going to cost you, Schulte! It's not going to go down that easily.
> I'll call the FTC, the FCC, the SCOTUS, the POTUS, the NYT, the BDFL, the
> NFL and the MLB: an outrage I tell you! An affront to the democratic rules
> some of us cherish! We'll fight to the death! Who's with me?

+1 #+name 

mj

Re: [RFC] Standardized code block keywords

[Eric Schulte]

Martyn Jago <martyn.jago@btinternet.com> writes:

> Nick Dokos <nicholas.dokos@hp.com> writes:
>
>> Eric Schulte <schulte.eric@gmail.com> wrote:
>>
>>> Surprisingly (to me) srcname is the winner here, but luckily I haven't
>>> yet voted, and although I would have though #+source: would have been
>>> the winner I like the simplicity of using #+name: for named code blocks
>>> as well as named data.  So I'll vote for #+name: here making it a tie,
>>> and I'll also take tie-breaking powers upon myself giving #+name: the
>>> win.
>>> 
>>
>> This is going to cost you, Schulte! It's not going to go down that easily.
>> I'll call the FTC, the FCC, the SCOTUS, the POTUS, the NYT, the BDFL, the
>> NFL and the MLB: an outrage I tell you! An affront to the democratic rules
>> some of us cherish! We'll fight to the death! Who's with me?
>

Ha!

Well at least SCOTUS should be on my side, as they seem to have no
problem giving some people more freedom than others.

>
> +1 #+name
>

Well thank goodness, even if I can't put my own thumb on the scale it
seems I can advertise enough to sway voters to my cause. :)

Cheers -- Eric

>
> mj
>
>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [RFC] Standardized code block keywords

[Nick Dokos]

Eric Schulte <schulte.eric@gmail.com> wrote:

> Martyn Jago <martyn.jago@btinternet.com> writes:
> 
> > Nick Dokos <nicholas.dokos@hp.com> writes:
> >
> >> Eric Schulte <schulte.eric@gmail.com> wrote:
> >>
> >>> Surprisingly (to me) srcname is the winner here, but luckily I haven't
> >>> yet voted, and although I would have though #+source: would have been
> >>> the winner I like the simplicity of using #+name: for named code blocks
> >>> as well as named data.  So I'll vote for #+name: here making it a tie,
> >>> and I'll also take tie-breaking powers upon myself giving #+name: the
> >>> win.
> >>> 
> >>
> >> This is going to cost you, Schulte! It's not going to go down that easily.
> >> I'll call the FTC, the FCC, the SCOTUS, the POTUS, the NYT, the BDFL, the
> >> NFL and the MLB: an outrage I tell you! An affront to the democratic rules
> >> some of us cherish! We'll fight to the death! Who's with me?
> >
> 
> Ha!
> 
> Well at least SCOTUS should be on my side, as they seem to have no
> problem giving some people more freedom than others.
> 

Indeed - but what about the NFL? I bet they have more integrity.


On second thought...

> >
> > +1 #+name
> >
> 

Back stabber!

> Well thank goodness, even if I can't put my own thumb on the scale it
> seems I can advertise enough to sway voters to my cause. :)
> 

Bribery and Corruption - what is the world coming to?

> Cheers -- Eric
> 
> >
> > mj
> >
> >
> 
> -- 
> Eric Schulte
> http://cs.unm.edu/~eschulte/
> 

Re: [RFC] Standardized code block keywords

[Daniel Bausch]

> > However, I'd like to ask, what happens, if one refers to a
> > name of a source block where data is expected, does it then refer to
> > the results produced by that source block?  How are such situations
> > handeled at the moment?
> 
> Try it out, but be ready to press C-g, because I would guess that it
> results in an infinite loop.

Isn't it possible to refer to the results of a code block as input data for 
another?  I thought it was.  If not currently then at least I suppose that it 
will be in the future.  The new syntax should be ready for that.

Daniel

Re: [RFC] Standardized code block keywords

[Daniel Bausch]

Am Dienstag 25 Oktober 2011, 19:21:22 schrieb Nick Dokos:
> Eric Schulte <schulte.eric@gmail.com> wrote:
> > Martyn Jago <martyn.jago@btinternet.com> writes:
> > > Nick Dokos <nicholas.dokos@hp.com> writes:
> > >> Eric Schulte <schulte.eric@gmail.com> wrote:
> > >>> Surprisingly (to me) srcname is the winner here, but luckily I
> > >>> haven't yet voted, and although I would have though #+source: would
> > >>> have been the winner I like the simplicity of using #+name: for
> > >>> named code blocks as well as named data.  So I'll vote for #+name:
> > >>> here making it a tie, and I'll also take tie-breaking powers upon
> > >>> myself giving #+name: the win.
> > >> 
> > >> This is going to cost you, Schulte! It's not going to go down that
> > >> easily. I'll call the FTC, the FCC, the SCOTUS, the POTUS, the NYT,
> > >> the BDFL, the NFL and the MLB: an outrage I tell you! An affront to
> > >> the democratic rules some of us cherish! We'll fight to the death!
> > >> Who's with me?
> > 
> > Ha!
> > 
> > Well at least SCOTUS should be on my side, as they seem to have no
> > problem giving some people more freedom than others.
> 
> Indeed - but what about the NFL? I bet they have more integrity.
> 
> 
> On second thought...
> 
> > > +1 #+name
> 
> Back stabber!

Oops, I didn't want to split the community.  Be nice to each other.

> > Well thank goodness, even if I can't put my own thumb on the scale it
> > seems I can advertise enough to sway voters to my cause. :)
> 
> Bribery and Corruption - what is the world coming to?
> 
> > Cheers -- Eric
> > 
> > > mj

Re: [RFC] Standardized code block keywords

[Thomas S. Dye]

Daniel Bausch <DanielBausch@gmx.de> writes:

>> > However, I'd like to ask, what happens, if one refers to a
>> > name of a source block where data is expected, does it then refer to
>> > the results produced by that source block?  How are such situations
>> > handeled at the moment?
>> 
>> Try it out, but be ready to press C-g, because I would guess that it
>> results in an infinite loop.
>
> Isn't it possible to refer to the results of a code block as input data for 
> another?  I thought it was.  If not currently then at least I suppose that it 
> will be in the future.  The new syntax should be ready for that.
>
> Daniel
>
Aloha Daniel,

Yes, it is already possible to refer to named :results as input data for
another source code block.  This is an important feature that makes it
possible to record intermediate results in the Org-mode file.

Also, passing the name of one source code block to a variable of another
source code block is called chaining.  This is an important feature that
makes it possible to do part of a computation in one language and then
another part in a different language, without having to write out
intermediate results.  AFAIK, there is no limit to this chaining
behavior.

I haven't run into an infinite loop doing either of these things,
perhaps because I've not written a source code block that refers to its
own results?

hth,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [RFC] Standardized code block keywords

[Eric Schulte]

Daniel Bausch <DanielBausch@gmx.de> writes:

>> > However, I'd like to ask, what happens, if one refers to a
>> > name of a source block where data is expected, does it then refer to
>> > the results produced by that source block?  How are such situations
>> > handeled at the moment?
>> 
>> Try it out, but be ready to press C-g, because I would guess that it
>> results in an infinite loop.
>
> Isn't it possible to refer to the results of a code block as input data for 
> another?  I thought it was.  If not currently then at least I suppose that it 
> will be in the future.  The new syntax should be ready for that.
>

Sorry for my confusion.  I thought you meant a case in which code block
A needs the results of code block B as an input parameter, but code
block B needs the results of code block A as an input parameter.  Such a
reciprocal dependency would result in an infinite loop.

But yes, the ability of one code block to call another and make use of
its results is (as Tom mentioned) one of the core features of code block
support in Org-mode.

Cheers -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [RFC] Standardized code block keywords

[Giovanni Ridolfi]

Nick Dokos <nicholas.dokos@hp.com> writes:

> Eric Schulte <schulte.eric@gmail.com> wrote:
>
>> Surprisingly (to me) srcname is the winner here, but luckily I haven't
>> yet voted, and although I would have though #+source: would have been
>> the winner I like the simplicity of using #+name: for named code blocks
>> as well as named data.  So I'll vote for #+name: here making it a tie,
>> and I'll also take tie-breaking powers upon myself giving #+name: the
>> win.
>> 
>
> This is going to cost you, Schulte! It's not going to go down that easily.
> I'll call the FTC, the FCC, the SCOTUS, the POTUS, the NYT, the BDFL, the
> NFL and the MLB: an outrage I tell you! An affront to the democratic rules
> some of us cherish! We'll fight to the death! Who's with me?

+1 srcname

:-)
Power to the people! Democracy forever!

Giovanni /who has not used babel yet.

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Sebastien Vauban]

Hi Eric,

Eric Schulte wrote:
>> I think that makes sense.
>>
>> While thinking about all of this, and working in real-life documents, I just
>> came back to a suggestion which I made some time ago. It goes about this
>> enhancement:
>>
>>     Would it be possible to specify "buffer-wide language specific" header
>>     arguments?
>
> Yes, this is already possible.  You can customize the
> org-babel-default-header-args:lang variable (where "lang" is the source
> name) as a file local variable.
>
>> That is, be able to say:
>>
>>     "In this document, I want to:
>>     - tangle all my .sql chunks, but no other;
>>     - eval all the elisp chunks with query, but no other."
>>
>> Something we could write quite easily along the lines:
>>
>>     #+PROPERTY:               tangle no
>>     #+PROPERTY:               eval never
>>     #+PROPERTY[SQL]:          tangle yes
>>     #+PROPERTY[EMACS-LISP]:   eval query
>>
>>     (the syntax used here is just a draft sample!)
>>
>
> I do not think we can customize the PROPERTY syntax as is exists outside
> of Babel.  The goal here was to piggy-back on top of rather than co-opt
> regular Org-mode syntax.

I understand that argument.

It's just that the current solution is not optimal (among others) for
documents mixing R and shell code: you don't want your "session" property to
be common between both languages (shell code sent to your R terminal, or
vice-versa).

But it's nice this case is already handled in a more generic way than on the
code blocks themselves, and I can live with that. Thanks again for your help.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [RFC] Standardized code block keywords

[Daniel Bausch]

Am Mittwoch 26 Oktober 2011, 15:10:03 schrieb Giovanni Ridolfi:
> Nick Dokos <nicholas.dokos@hp.com> writes:
> > Eric Schulte <schulte.eric@gmail.com> wrote:
> >> Surprisingly (to me) srcname is the winner here, but luckily I haven't
> >> yet voted, and although I would have though #+source: would have been
> >> the winner I like the simplicity of using #+name: for named code blocks
> >> as well as named data.  So I'll vote for #+name: here making it a tie,
> >> and I'll also take tie-breaking powers upon myself giving #+name: the
> >> win.
> > 
> > This is going to cost you, Schulte! It's not going to go down that
> > easily. I'll call the FTC, the FCC, the SCOTUS, the POTUS, the NYT, the
> > BDFL, the NFL and the MLB: an outrage I tell you! An affront to the
> > democratic rules some of us cherish! We'll fight to the death! Who's
> > with me?
> 
> +1 srcname
> 
> :-)
> 
> Power to the people! Democracy forever!
> 
> Giovanni /who has not used babel yet.

Hmm, then you don't know what we are talking about and should abstain from 
voting. ;-)
--
Daniel (who used Babel to write his thesis in one big file with all data and 
chart generating code interleaved with the text -- faboulous!)

Re: [RFC] Standardized code block keywords

[Nick Dokos]

Daniel Bausch <DanielBausch@gmx.de> wrote:

> Am Mittwoch 26 Oktober 2011, 15:10:03 schrieb Giovanni Ridolfi:
> > Nick Dokos <nicholas.dokos@hp.com> writes:
> > > Eric Schulte <schulte.eric@gmail.com> wrote:
> > >> Surprisingly (to me) srcname is the winner here, but luckily I haven't
> > >> yet voted, and although I would have though #+source: would have been
> > >> the winner I like the simplicity of using #+name: for named code blocks
> > >> as well as named data.  So I'll vote for #+name: here making it a tie,
> > >> and I'll also take tie-breaking powers upon myself giving #+name: the
> > >> win.
> > > 
> > > This is going to cost you, Schulte! It's not going to go down that
> > > easily. I'll call the FTC, the FCC, the SCOTUS, the POTUS, the NYT, the
> > > BDFL, the NFL and the MLB: an outrage I tell you! An affront to the
> > > democratic rules some of us cherish! We'll fight to the death! Who's
> > > with me?
> > 
> > +1 srcname
> > 
> > :-)
> > 
> > Power to the people! Democracy forever!
> > 
> > Giovanni /who has not used babel yet.
> 
> Hmm, then you don't know what we are talking about and should abstain from 
> voting. ;-)

That's another blatant attempt to subvert democracy by the Schulte
cabal: whoever said that one has to know anything about it before
voting? Both recent and distant history prove that that is not the case
(e.g. watch Ken Burns's "Prohibition" and weep - or laugh - or both).

> --
> Daniel (who used Babel to write his thesis in one big file with all data and 
> chart generating code interleaved with the text -- faboulous!)
> 
> 

Indeed - could we hope to get a glimpse at some examples (or even the whole
thing) at some point?

Nick

PS. I presume it's clear to all that this silliness I started has a big
smilie wrapped around the whole thing, but just in case somebody decides
that I'm serious: pthvhtthththtttt :-)

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Eric Schulte]

"Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:

> Hi Eric,
>
> Eric Schulte wrote:
>>> I think that makes sense.
>>>
>>> While thinking about all of this, and working in real-life documents, I just
>>> came back to a suggestion which I made some time ago. It goes about this
>>> enhancement:
>>>
>>>     Would it be possible to specify "buffer-wide language specific" header
>>>     arguments?
>>
>> Yes, this is already possible.  You can customize the
>> org-babel-default-header-args:lang variable (where "lang" is the source
>> name) as a file local variable.
>>

Hi Seb,                                  ^
                                         |
I just wanted to make sure you saw the above solution for specifying
file-wide language-specific header arguments.  Emacs' support for buffer
local variables makes this fairly easy to implement.  In fact buffer
local variables could also be used to specify multi-langauge file-wide
header arguments using the `org-babel-default-header-args' variable.

Cheers -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [RFC] Standardized code block keywords

[Daniel Bausch]

> > Daniel (who used Babel to write his thesis in one big file with all data
> > and chart generating code interleaved with the text -- faboulous!)
> 
> Indeed - could we hope to get a glimpse at some examples (or even the whole
> thing) at some point?

Unfortunately not at the moment, because we're still in the process of getting 
the topic published.
 
> Nick
> 
> PS. I presume it's clear to all that this silliness I started has a big
> smilie wrapped around the whole thing, but just in case somebody decides
> that I'm serious: pthvhtthththtttt :-)

Yeah, that's clear. :-D

Have a nice day
Daniel

Re: [RFC] Standardized code block keywords

[Eric Schulte]

[-- Attachment #1: Type: text/plain, Size: 424 bytes --]

The attached patch implements these changes, please see the patch
comment as it contains all of the pertinent information.

If any brave volunteers would be willing to test this patch locally
before I apply it to the Org-mode git repository that would be greatly
appreciated.

Thanks to the test suite the most egregious bugs introduced by my first
version of this patch have already been caught and fixed.

Cheers -- Eric


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-removing-code-block-results-and-call-line-synonyms-B.patch --]
[-- Type: text/x-diff, Size: 23911 bytes --]

From a708aced9e29504637ac1d2ce3203fb796081a7e Mon Sep 17 00:00:00 2001
From: Eric Schulte <schulte.eric@gmail.com>
Date: Fri, 28 Oct 2011 10:44:21 -0600
Subject: [PATCH] removing code block, results and call-line synonyms -- BREAKING CHANGE

Following a round of on-list discussion many code block synonyms have
been removed, moving forward the following syntax is valid.

- call lines are specified with #+call:
- code blocks are named with #+name:
- results are named with #+name:, however results generated by a code
  block may still be labeled with #+results:, and tables named with
  #+tblname: will be considered to be named results

The following function may be used to update an existing Org-mode
buffer to the new syntax.

  (defun update-org-buffer ()
    "Update an Org-mode buffer to the new data, code block and call line syntax."
    (interactive)
    (save-excursion
      (flet ((to-re (lst) (concat "^[ \t]*#\\+" (regexp-opt lst t)
                                  "\\(\\[\\([[:alnum:]]+\\)\\]\\)?\\:[ \t]*"))
             (update (re new)
                     (goto-char (point-min))
                     (while (re-search-forward re nil t)
                       (replace-match new nil nil nil 1))))
        (let ((old-re (to-re '("RESULTS" "DATA" "SRCNAME" "SOURCE")))
              (lob-re (to-re '("LOB")))
              (case-fold-search t))
          (update old-re "name")
          (update lob-re "call")))))

Note: If an old version of Org-mode (e.g., the one shipped with Emacs)
      is installed on your system many of the important variables will
      be pre-defined with a defvar and *will not* have their values
      automatically updated, these include the following.
      - org-babel-data-names
      - org-babel-result-regexp
      - org-babel-src-block-regexp
      - org-babel-src-name-regexp
      - org-babel-src-name-w-name-regexp
      It may be necessary to either remove the source code of older
      versions of Org-mode, or to explicitly evaluate the ob.el file.

* lisp/ob-exp.el (org-exp-res/src-name-cleanup): Updated
  Documentation.
* lisp/ob-lob.el (org-babel-block-lob-one-liner-regexp): Updated
  regular expression.
  (org-babel-inline-lob-one-liner-regexp): Updated regular expression.
* lisp/ob-ref.el (org-babel-ref-resolve): Notice when something that
  looks like a data results may actually be a code block.
* lisp/ob-table.el: Updated documentation.
* lisp/ob.el (org-babel-src-name-regexp): Simplified regexp.
  (org-babel-get-src-block-info): Updated match strings.
  (org-babel-data-names): Simplified acceptable names.
  (org-babel-find-named-block): Indentation.
  (org-babel-find-named-result): Updated to not return a code block as
  a result.
* lisp/org.el (org-fontify-meta-lines-and-blocks-1): Removing
  references to old syntactic elements.
  (org-additional-option-like-keywords): Removing references to old
  syntactic elements.
* contrib/babel/library-of-babel.org: Updated to make use of the new
  syntax.
* testing/examples/babel-dangerous.org: Updated to make use of the new
  syntax.
* testing/examples/babel.org: Updated to make use of the new syntax.
* testing/examples/ob-awk-test.org: Updated to make use of the new
  syntax.
* testing/examples/ob-fortran-test.org: Updated to make use of the new
  syntax.
* testing/lisp/test-ob.el: Removed two bad tests which tested the
  literal values of old regular expressions rather than their
  behavior.
---
 contrib/babel/library-of-babel.org   |   48 +++++++++++++++++-----------------
 lisp/ob-exp.el                       |    2 +-
 lisp/ob-lob.el                       |   13 +--------
 lisp/ob-ref.el                       |    4 +++
 lisp/ob-table.el                     |    2 +-
 lisp/ob.el                           |   30 ++++++++++++---------
 lisp/org.el                          |    9 ++----
 testing/examples/babel-dangerous.org |    5 +++-
 testing/examples/babel.org           |   30 ++++++++++----------
 testing/examples/ob-awk-test.org     |    4 +-
 testing/examples/ob-fortran-test.org |    4 +-
 testing/lisp/test-ob.el              |   42 -----------------------------
 12 files changed, 75 insertions(+), 118 deletions(-)

diff --git a/contrib/babel/library-of-babel.org b/contrib/babel/library-of-babel.org
index 2db9d4c..571eb70 100644
--- a/contrib/babel/library-of-babel.org
+++ b/contrib/babel/library-of-babel.org
@@ -22,7 +22,7 @@
 
 A collection of simple utility functions:
 
-#+srcname: echo
+#+name: echo
 #+begin_src emacs-lisp :var input="echo'd"
   input
 #+end_src
@@ -35,7 +35,7 @@ Read the contents of the file at =file=.  The =:results vector= and
 =:results scalar= header arguments can be used to read the contents of
 file as either a table or a string.
 
-#+srcname: read
+#+name: read
 #+begin_src emacs-lisp :var file="" :var format=""
   (if (string= format "csv")
       (with-temp-buffer
@@ -49,7 +49,7 @@ file as either a table or a string.
 Write =data= to a file at =file=.  If =data= is a list, then write it
 as a table in traditional Org-mode table syntax.
 
-#+srcname: write
+#+name: write
 #+begin_src emacs-lisp :var data="" :var file="" :var ext='()
   (flet ((echo (r) (if (stringp r) r (format "%S" r))))
     (with-temp-file file
@@ -67,7 +67,7 @@ as a table in traditional Org-mode table syntax.
 
 Read local or remote file in [[http://www.json.org/][json]] format into emacs-lisp objects.
 
-#+srcname: json
+#+name: json
 #+begin_src emacs-lisp :var file='() :var url='()
   (require 'json)
   (cond
@@ -96,7 +96,7 @@ The =google= command seems to be throwing "Moved Temporarily" errors
 when trying to download textual documents, but this is working fine
 for spreadsheets.
 
-#+source: gdoc-read
+#+name: gdoc-read
 #+begin_src emacs-lisp :var title="example" :var format="csv"
   (let* ((file (concat title "." format))
          (cmd (format "google docs get --format %S --title %S" format title)))
@@ -126,7 +126,7 @@ Write =data= to a google document named =title=.  If =data= is tabular
 it will be saved to a spreadsheet, otherwise it will be saved as a
 normal document.
 
-#+source: gdoc-write
+#+name: gdoc-write
 #+begin_src emacs-lisp :var title="babel-upload" :var data=fibs(n=10) :results silent
   (let* ((format (if (listp data) "csv" "txt"))
          (tmp-file (make-temp-file "org-babel-google-doc" nil (concat "." format)))
@@ -157,7 +157,7 @@ example usage
   Plot column 2 (y axis) against column 1 (x axis). Columns 3 and
   beyond, if present, are ignored.
 
-#+srcname: R-plot(data=R-plot-example-data)
+#+name: R-plot(data=R-plot-example-data)
 #+begin_src R
 plot(data)
 #+end_src
@@ -169,7 +169,7 @@ plot(data)
 | 4 | 16 |
 | 5 | 25 |
 
-#+lob: R-plot(data=R-plot-example-data)
+#+call: R-plot(data=R-plot-example-data)
 
 #+resname: R-plot(data=R-plot-example-data)
 : nil
@@ -180,7 +180,7 @@ plot(data)
 
 ** Headline references
 
-#+source: headline
+#+name: headline
 #+begin_src emacs-lisp :var headline=top :var file='()
   (save-excursion
     (when file (get-file-buffer file))
@@ -217,7 +217,7 @@ optional.
 | env   | optional environment, default to "tabular" |
 | width | optional width specification string        |
 
-#+srcname: booktabs
+#+name: booktabs
 #+begin_src emacs-lisp :var table='((:head) hline (:body)) :var align='() :var env="tabular" :var width='() :noweb yes :results latex
   (flet ((to-tab (tab)
                  (orgtbl-to-generic
@@ -266,7 +266,7 @@ are optional.
 | foot      | optional "foot" string                                      |
 | lastfoot  | optional "lastfoot" string                                  |
 
-#+srcname: longtable
+#+name: longtable
 #+begin_src emacs-lisp :var table='((:table)) :var align='() :var width='() :var hline="\\hline" :var firsthead='() :var head='() :var foot='() :var lastfoot='() :noweb yes :results latex
   (org-fill-template
    "
@@ -314,7 +314,7 @@ span. Note the use of LaTeX, rather than Org-mode, markup.
 #+tblname: arguments-notes
 | \multicolumn{2}{l}{This is a footnote to the \emph{arguments} table.} |
 
-#+srcname: booktabs-notes
+#+name: booktabs-notes
 #+begin_src emacs-lisp :var table='((:head) hline (:body)) :var notes='() :var align='() :var env="tabular" :var width='() :var lspace='() :noweb yes :results latex
   (flet ((to-tab (tab)
                  (orgtbl-to-generic
@@ -356,7 +356,7 @@ span. Note the use of LaTeX, rather than Org-mode, markup.
 | 1 | 2 | 3 |
 | 4 | 5 | 6 |
 
-#+srcname: transpose
+#+name: transpose
 #+begin_src emacs-lisp :var table=transpose-example
   (apply #'mapcar* #'list table)
 #+end_src
@@ -372,7 +372,7 @@ span. Note the use of LaTeX, rather than Org-mode, markup.
 | 1 | 2 | 3 |
 | a | b | c |
 
-#+source: all-to-string
+#+name: all-to-string
 #+begin_src emacs-lisp :var tbl='()
   (defun all-to-string (tbl)
     (if (listp tbl)
@@ -387,7 +387,7 @@ span. Note the use of LaTeX, rather than Org-mode, markup.
   (mapcar (lambda (row) (mapcar (lambda (cell) (stringp cell)) row)) tbl)
 #+end_src
 
-#+results:
+#+name:
 | nil | nil | nil |
 | t   | t   | t   |
 
@@ -395,7 +395,7 @@ span. Note the use of LaTeX, rather than Org-mode, markup.
   (mapcar (lambda (row) (mapcar (lambda (cell) (stringp cell)) row)) tbl)
 #+end_src
 
-#+results:
+#+name:
 | t | t | t |
 | t | t | t |
 
@@ -412,7 +412,7 @@ export. The function uses the Emacs VC commands to interface to the
 local version control system, but has only been tested to work with
 Git. 'limit' is currently unsupported.
 
-#+source: vc-log
+#+name: vc-log
 #+headers: :var limit=-1
 #+headers: :var buf=(buffer-name (current-buffer))
 #+begin_src emacs-lisp
@@ -440,34 +440,34 @@ Git. 'limit' is currently unsupported.
 
 ** Trivial python code blocks
 
-#+srcname: python-identity(a=1)
+#+name: python-identity(a=1)
 #+begin_src python
 a
 #+end_src
 
-#+srcname: python-add(a=1, b=2)
+#+name: python-add(a=1, b=2)
 #+begin_src python
 a + b
 #+end_src
 
 ** Arithmetic
 
-#+source: lob-add
+#+name: lob-add
 #+begin_src emacs-lisp :var a=0 :var b=0
   (+ a b)
 #+end_src
 
-#+source: lob-minus
+#+name: lob-minus
 #+begin_src emacs-lisp :var a=0 :var b=0
   (- a b)
 #+end_src
 
-#+source: lob-times
+#+name: lob-times
 #+begin_src emacs-lisp :var a=0 :var b=0
   (* a b)
 #+end_src
 
-#+source: lob-div
+#+name: lob-div
 #+begin_src emacs-lisp :var a=0 :var b=0
   (/ a b)
 #+end_src
@@ -477,7 +477,7 @@ a + b
 The =elispgantt= source block was sent to the mailing list by Eric
 Fraga.  It was modified slightly by Tom Dye.
  
-#+source: elispgantt
+#+name: elispgantt
 #+begin_src emacs-lisp :var table=gantttest
   (let ((dates "")
         (entries (nthcdr 2 table))
diff --git a/lisp/ob-exp.el b/lisp/ob-exp.el
index 3b102e1..e4fae80 100644
--- a/lisp/ob-exp.el
+++ b/lisp/ob-exp.el
@@ -147,7 +147,7 @@ options and are taken from `org-babel-default-inline-header-args'."
 		(forward-char 2)))))))))
 
 (defun org-exp-res/src-name-cleanup ()
-  "Clean up #+results and #+srcname lines for export.
+  "Clean up #+results and #+name lines for export.
 This function should only be called after all block processing
 has taken place."
   (interactive)
diff --git a/lisp/ob-lob.el b/lisp/ob-lob.el
index be3033e..73f9553 100644
--- a/lisp/ob-lob.el
+++ b/lisp/ob-lob.el
@@ -61,24 +61,15 @@ To add files to this list use the `org-babel-lob-ingest' command."
 	     lob-ingest-count (if (> lob-ingest-count 1) "s" ""))
     lob-ingest-count))
 
-(defconst org-babel-lob-call-aliases '("lob" "call")
-  "Aliases to call a source block function.
-If you change the value of this variable then your files may
-  become unusable by other org-babel users, and vice versa.")
-
 (defconst org-babel-block-lob-one-liner-regexp
   (concat
-   "^\\([ \t]*\\)#\\+\\(?:"
-   (mapconcat #'regexp-quote org-babel-lob-call-aliases "\\|")
-   "\\):[ \t]+\\([^\(\)\n]+?\\)\\(\\[\\(.*\\)\\]\\|\\(\\)\\)"
+   "^\\([ \t]*\\)#\\+call:[ \t]+\\([^\(\)\n]+?\\)\\(\\[\\(.*\\)\\]\\|\\(\\)\\)"
    "\(\\([^\n]*\\)\)\\(\\[.+\\]\\|\\)[ \t]*\\(\\([^\n]*\\)\\)?")
   "Regexp to match non-inline calls to predefined source block functions.")
 
 (defconst org-babel-inline-lob-one-liner-regexp
   (concat
-   "\\([^\n]*\\)\\(?:"
-   (mapconcat #'regexp-quote org-babel-lob-call-aliases "\\|")
-   "\\)_\\([^\(\)\n]+?\\)\\(\\[\\(.*\\)\\]\\|\\(\\)\\)"
+   "\\([^\n]*\\)call_\\([^\(\)\n]+?\\)\\(\\[\\(.*\\)\\]\\|\\(\\)\\)"
    "\(\\([^\n]*\\)\)\\(\\[\\(.*?\\)\\]\\)?")
   "Regexp to match inline calls to predefined source block functions.")
 
diff --git a/lisp/ob-ref.el b/lisp/ob-ref.el
index bff3b3f..fcaeba0 100644
--- a/lisp/ob-ref.el
+++ b/lisp/ob-ref.el
@@ -173,6 +173,10 @@ the variable."
 	(cond
 	 (lob-info (setq type 'lob))
 	 (id (setq type 'id))
+	 ((and (looking-at org-babel-src-name-regexp)
+	       (progn (forward-line 1)
+		      (looking-at org-babel-src-block-regexp)))
+	  (setq type 'source-block))
 	 (t (while (not (setq type (org-babel-ref-at-ref-p)))
 	      (forward-line 1)
 	      (beginning-of-line)
diff --git a/lisp/ob-table.el b/lisp/ob-table.el
index 1cee16e..15ebff9 100644
--- a/lisp/ob-table.el
+++ b/lisp/ob-table.el
@@ -30,7 +30,7 @@
 ;;   (defun fibbd (n) (if (< n 2) 1 (+ (fibbd (- n 1)) (fibbd (- n 2)))))
 ;; #+end_src
 
-;; #+srcname: fibbd
+;; #+name: fibbd
 ;; #+begin_src emacs-lisp :var n=2 :results silent
 ;; (fibbd n)
 ;; #+end_src
diff --git a/lisp/ob.el b/lisp/ob.el
index 4438ee8..5d52f95 100644
--- a/lisp/ob.el
+++ b/lisp/ob.el
@@ -113,7 +113,7 @@ remove code block execution from the C-c C-c keybinding."
   :type 'boolean)
 
 (defvar org-babel-src-name-regexp
-  "^[ \t]*#\\+\\(srcname\\|source\\|function\\):[ \t]*"
+  "^[ \t]*#\\+name:[ \t]*"
   "Regular expression used to match a source name line.")
 
 (defvar org-babel-multi-line-header-regexp
@@ -216,8 +216,8 @@ Returns a list
 		   (nth 2 info)
 		   (org-babel-parse-header-arguments (match-string 1)))))
 	  (when (looking-at org-babel-src-name-w-name-regexp)
-	    (setq name (org-babel-clean-text-properties (match-string 4)))
-	    (when (match-string 6)
+	    (setq name (org-babel-clean-text-properties (match-string 3)))
+	    (when (match-string 5)
 	      (setf (nth 2 info) ;; merge functional-syntax vars and header-args
 		    (org-babel-merge-params
 		     (mapcar
@@ -229,7 +229,7 @@ Returns a list
 			   (error
 			    "variable \"%s\"%s must be assigned a default value"
 			    var (if name (format " in block \"%s\"" name) ""))))
-		       (org-babel-ref-split-args (match-string 6))))
+		       (org-babel-ref-split-args (match-string 5))))
 		     (nth 2 info))))))
       ;; inline source block
       (when (org-babel-get-inline-src-block-matches)
@@ -396,7 +396,7 @@ specific header arguments as well.")
   '((:session . "none") (:results . "replace") (:exports . "results"))
   "Default arguments to use when evaluating an inline source block.")
 
-(defvar org-babel-data-names '("TBLNAME" "RESNAME" "RESULTS" "DATA"))
+(defvar org-babel-data-names '("TBLNAME" "RESULTS" "NAME"))
 
 (defvar org-babel-result-regexp
   (concat "^[ \t]*#\\+"
@@ -1359,7 +1359,7 @@ org-babel-named-src-block-regexp."
 	  (regexp (org-babel-named-src-block-regexp-for-name name)) msg)
       (goto-char (point-min))
       (when (or (re-search-forward regexp nil t)
-                (re-search-backward regexp nil t))
+		(re-search-backward regexp nil t))
         (match-beginning 0)))))
 
 (defun org-babel-src-block-names (&optional file)
@@ -1368,7 +1368,7 @@ org-babel-named-src-block-regexp."
     (when file (find-file file)) (goto-char (point-min))
     (let (names)
       (while (re-search-forward org-babel-src-name-w-name-regexp nil t)
-	(setq names (cons (match-string 4) names)))
+	(setq names (cons (match-string 3) names)))
       names)))
 
 ;;;###autoload
@@ -1384,16 +1384,20 @@ org-babel-named-src-block-regexp."
         (progn (goto-char point) (org-show-context))
       (message "result '%s' not found in this buffer" name))))
 
-(defun org-babel-find-named-result (name)
+(defun org-babel-find-named-result (name &optional point)
   "Find a named result.
 Return the location of the result named NAME in the current
 buffer or nil if no such result exists."
   (save-excursion
-    (goto-char (point-min))
-    (when (re-search-forward
-           (concat org-babel-result-regexp
-                   "[ \t]" (regexp-quote name) "[ \t\n\f\v\r]") nil t)
-      (beginning-of-line 0) (point))))
+    (goto-char (or point (point-min)))
+    (catch 'is-a-code-block
+      (when (re-search-forward
+	     (concat org-babel-result-regexp
+		     "[ \t]" (regexp-quote name) "[ \t\n\f\v\r]") nil t)
+	(when (and (string= "name" (match-string 1))
+		   (looking-at org-babel-src-block-regexp))
+	  (throw 'is-a-code-block (org-babel-find-named-result name (point))))
+	(beginning-of-line 0) (point)))))
 
 (defun org-babel-result-names (&optional file)
   "Returns the names of results in FILE or the current buffer."
diff --git a/lisp/org.el b/lisp/org.el
index 2599d41..e23242e 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5400,9 +5400,8 @@ will be prompted for."
 	     '(font-lock-fontified t face org-meta-line))
 	    t)
 	   ((or (member dc1 '("begin:" "end:" "caption:" "label:"
-			      "orgtbl:" "tblfm:" "tblname:" "result:"
-			      "results:" "source:" "srcname:" "call:"
-			      "data:" "header:" "headers:"))
+			      "orgtbl:" "tblfm:" "tblname:" "results:"
+			      "call:" "header:" "headers:"))
 		(and (match-end 4) (equal dc3 "attr")))
 	    (add-text-properties
 	     beg (match-end 0)
@@ -10966,10 +10965,8 @@ This function can be used in a hook."
     "BEGIN_CENTER" "END_CENTER"
     "BEGIN_SRC" "END_SRC"
     "BEGIN_RESULT" "END_RESULT"
-    "SOURCE:" "SRCNAME:" "FUNCTION:"
-    "RESULTS:" "DATA:"
+    "NAME:" "RESULTS:"
     "HEADER:" "HEADERS:"
-    "BABEL:"
     "CATEGORY:" "COLUMNS:" "PROPERTY:"
     "CAPTION:" "LABEL:"
     "SETUPFILE:"
diff --git a/testing/examples/babel-dangerous.org b/testing/examples/babel-dangerous.org
index 63f9f27..8ec9fa6 100644
--- a/testing/examples/babel-dangerous.org
+++ b/testing/examples/babel-dangerous.org
@@ -9,7 +9,10 @@
 There is no default value assigned to =x= variable. This is not permitted
 anymore.
 
-#+source: carre(x)
+#+name: carre(x)
 #+begin_src python
   return x*x
 #+end_src
+
+#+name: carre
+
diff --git a/testing/examples/babel.org b/testing/examples/babel.org
index 9c61b0c..45d0171 100644
--- a/testing/examples/babel.org
+++ b/testing/examples/babel.org
@@ -6,7 +6,7 @@
   :ID:       eb1f6498-5bd9-45e0-9c56-50717053e7b7
   :END:
 
-#+source: noweb-example
+#+name: noweb-example
 #+begin_src emacs-lisp
   (message "expanded")
 #+end_src
@@ -39,7 +39,7 @@
   prop
 #+end_src
 
-#+results:
+#+name:
 : 4
 
 * excessive id links on tangling
@@ -64,7 +64,7 @@
   :ID:       f68821bc-7f49-4389-85b5-914791ee3718
   :END:
 
-#+source: four
+#+name: four
 #+begin_src emacs-lisp
   (list 1 2 3 4)
 #+end_src
@@ -73,7 +73,7 @@
   (length four)
 #+end_src
 
-#+results:
+#+name:
 : 4
 
 * multi-line header arguments
@@ -86,7 +86,7 @@
   (map 'list #'list numbers letters)
 #+end_src
 
-#+results:
+#+name:
 | 1 | a |
 | 2 | b |
 | 3 | c |
@@ -100,15 +100,15 @@
   :ID:       0d82b52d-1bb9-4916-816b-2c67c8108dbb
   :END:
 
-#+source: i-have-a-name
+#+name: i-have-a-name
 #+begin_src emacs-lisp
   42
 #+end_src
 
-#+results: 
+#+name: 
 : 42
 
-#+results: i-have-a-name
+#+name: i-have-a-name
 : 42
 
 * Pascal's Triangle -- export test
@@ -116,7 +116,7 @@
   :ID:       92518f2a-a46a-4205-a3ab-bcce1008a4bb
   :END:
 
-#+source: pascals-triangle
+#+name: pascals-triangle
 #+begin_src emacs-lisp :var n=5 :exports both
   (defun pascals-triangle (n)
     (if (= n 0)
@@ -136,7 +136,7 @@
   :ID:       6d2ff4ce-4489-4e2a-9c65-e3f71f77d975
   :END:
 
-#+source: take-sqrt
+#+name: take-sqrt
 #+begin_src emacs-lisp :var n=9
   (sqrt n)
 #+end_src
@@ -159,7 +159,7 @@ This is an inline call call_echo(input="testing")[:results vector] embedded in p
 call_echo("testing")
 call_concat(1,2,3)
 
-#+source: concat
+#+name: concat
 #+begin_src emacs-lisp :var a=0 :var b=0 :var c=0
   (format "%S%S%S" a b c)
 #+end_src
@@ -169,7 +169,7 @@ call_concat(1,2,3)
   :ID:       72ddeed3-2d17-4c7f-8192-a575d535d3fc
   :END:
 
-#+source: double
+#+name: double
 #+begin_src emacs-lisp :var it=0
   (* 2 it)
 #+end_src
@@ -214,7 +214,7 @@ src_sh{echo 3} Here is one at the beginning of a line.
   :PROPERTIES:
   :ID:       5daa4d03-e3ea-46b7-b093-62c1b7632df3
   :END:
-#+results: a-list
+#+name: a-list
 - a
 - b
 - c
@@ -298,13 +298,13 @@ src_sh{echo 2} blocks on the src_emacs-lisp{"same"} line
   echo "[[file:./cv.cls]]"
 #+end_src
 
-#+results:
+#+name:
 : [[file:./cv.cls]]
 
 #+begin_src sh :results raw scalar
    echo "[[file:./cv.cls]]"
 #+end_src
 
-#+results:
+#+name:
 [[file:./cv.cls]]
 
diff --git a/testing/examples/ob-awk-test.org b/testing/examples/ob-awk-test.org
index 7f51772..9a33bf8 100644
--- a/testing/examples/ob-awk-test.org
+++ b/testing/examples/ob-awk-test.org
@@ -20,7 +20,7 @@ Use a code block ouput as an input
 #+end_src
 
 Use input file
-#+srcname: genfile
+#+name: genfile
 #+begin_src awk  :in-file ob-awk-test.in :results silent
     $0~/[\t]*#/{
         # skip comments 
@@ -33,7 +33,7 @@ Use input file
 
 * Input data generators
 A code block to generate input stream
-#+srcname: genseq
+#+name: genseq
 #+begin_src emacs-lisp :results silent
 (print "1")
 #+end_src
diff --git a/testing/examples/ob-fortran-test.org b/testing/examples/ob-fortran-test.org
index d48ae4e..47931bf 100644
--- a/testing/examples/ob-fortran-test.org
+++ b/testing/examples/ob-fortran-test.org
@@ -5,12 +5,12 @@
   :PROPERTIES:
   :ID:       459384e8-1797-4f11-867e-dde0473ea7cc
   :END:
-#+source: hello
+#+name: hello
 #+begin_src fortran :results silent
 print *, 'Hello world'
 #+end_src
 
-#+source: fortran_parameter
+#+name: fortran_parameter
 #+begin_src fortran :results silent
 integer, parameter :: i = 10
 write (*, '(i2)') i
diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el
index 58ff756..738df52 100644
--- a/testing/lisp/test-ob.el
+++ b/testing/lisp/test-ob.el
@@ -13,36 +13,6 @@
   (require 'org-test)
   (require 'org-test-ob-consts))
 
-(ert-deftest test-org-babel/src-name-regexp ()
-  (should(equal "^[ \t]*#\\+\\(srcname\\|source\\|function\\):[ \t]*"
-		org-babel-src-name-regexp))
-  (mapcar (lambda (name) 
-	    (should (org-test-string-exact-match
-		     org-babel-src-name-regexp
-		     (concat
-		      "   \t #+"
-		      name
-		      ":    \t src-name \t blah blah blah ")))
-	    (should (string-match
-		     org-babel-src-name-regexp
-		     (concat 
-		      "#+" (upcase name)
-		      ": src-name")))
-	    ;;TODO This should fail no?
-	    (should (org-test-string-exact-match
-		     org-babel-src-name-regexp
-		     (concat
-		      "#+" name ":")))
-	    ;;TODO Check - should this pass?
-	    (should (not (org-test-string-exact-match
-			  org-babel-src-name-regexp
-			  (concat
-			   "#+" name " : src-name")))))
-	  '("srcname" "source" "function"))
-  (should (not  (org-test-string-exact-match
-		 org-babel-src-name-regexp
-		 "#+invalid-name: src-name"))))
-
 (ert-deftest test-org-babel/multi-line-header-regexp ()
   (should(equal "^[ \t]*#\\+headers?:[ \t]*\\([^\n]*\\)$"
 		org-babel-multi-line-header-regexp))
@@ -63,18 +33,6 @@
 	 org-babel-multi-line-header-regexp
 	 "   \t #+headers : blah1 blah2 blah3 \t\n\t\n blah4 blah5 blah6 \n"))))
 
-(ert-deftest test-org-babel/src-name-w-name-regexp ()
-  (should(equal
-	  (concat org-babel-src-name-regexp "\\("
-		  org-babel-multi-line-header-regexp "\\)*"
-		  "\\([^ ()\f\t\n\r\v]+\\)\\(\(\\(.*\\)\)\\|\\)")
-	  org-babel-src-name-w-name-regexp))
-  (should (org-test-string-exact-match
-	   org-babel-src-name-w-name-regexp
-	   (concat
-	    "#+srcname: src-name "
-	    "#+headers: blah1 blah2 blah3 \t\n\t\n blah4 blah5 blah6 \n"))))
-
 (ert-deftest test-org-babel/src-block-regexp ()
   (let ((test-block
 	 (concat
-- 
1.7.4.1


[-- Attachment #3: Type: text/plain, Size: 47 bytes --]


-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [RFC] Standardized code block keywords

[Eric Schulte]

[-- Attachment #1: Type: text/plain, Size: 57 bytes --]

The attached updated patch fixes a bug in the original.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-removing-code-block-results-and-call-line-synonyms-B.patch --]
[-- Type: text/x-diff, Size: 24033 bytes --]

From 0e43d59ee8d46a63f86780a502de726271bc39de Mon Sep 17 00:00:00 2001
From: Eric Schulte <schulte.eric@gmail.com>
Date: Fri, 28 Oct 2011 10:44:21 -0600
Subject: [PATCH] removing code block, results and call-line synonyms -- BREAKING CHANGE

Following a round of on-list discussion many code block synonyms have
been removed, moving forward the following syntax is valid.

- call lines are specified with #+call:
- code blocks are named with #+name:
- results are named with #+name:, however results generated by a code
  block may still be labeled with #+results:, and tables named with
  #+tblname: will be considered to be named results

The following function may be used to update an existing Org-mode
buffer to the new syntax.

  (defun update-org-buffer ()
    "Update an Org-mode buffer to the new data, code block and call line syntax."
    (interactive)
    (save-excursion
      (flet ((to-re (lst) (concat "^[ \t]*#\\+" (regexp-opt lst t)
                                  "\\(\\[\\([[:alnum:]]+\\)\\]\\)?\\:[ \t]*"))
             (update (re new)
                     (goto-char (point-min))
                     (while (re-search-forward re nil t)
                       (replace-match new nil nil nil 1))))
        (let ((old-re (to-re '("RESULTS" "DATA" "SRCNAME" "SOURCE")))
              (lob-re (to-re '("LOB")))
              (case-fold-search t))
          (update old-re "name")
          (update lob-re "call")))))

Note: If an old version of Org-mode (e.g., the one shipped with Emacs)
      is installed on your system many of the important variables will
      be pre-defined with a defvar and *will not* have their values
      automatically updated, these include the following.
      - org-babel-data-names
      - org-babel-result-regexp
      - org-babel-src-block-regexp
      - org-babel-src-name-regexp
      - org-babel-src-name-w-name-regexp
      It may be necessary to either remove the source code of older
      versions of Org-mode, or to explicitly evaluate the ob.el file.

* lisp/ob-exp.el (org-exp-res/src-name-cleanup): Updated
  Documentation.
* lisp/ob-lob.el (org-babel-block-lob-one-liner-regexp): Updated
  regular expression.
  (org-babel-inline-lob-one-liner-regexp): Updated regular expression.
* lisp/ob-ref.el (org-babel-ref-resolve): Notice when something that
  looks like a data results may actually be a code block.
* lisp/ob-table.el: Updated documentation.
* lisp/ob.el (org-babel-src-name-regexp): Simplified regexp.
  (org-babel-get-src-block-info): Updated match strings.
  (org-babel-data-names): Simplified acceptable names.
  (org-babel-find-named-block): Indentation.
  (org-babel-find-named-result): Updated to not return a code block as
  a result.
* lisp/org.el (org-fontify-meta-lines-and-blocks-1): Removing
  references to old syntactic elements.
  (org-additional-option-like-keywords): Removing references to old
  syntactic elements.
* contrib/babel/library-of-babel.org: Updated to make use of the new
  syntax.
* testing/examples/babel-dangerous.org: Updated to make use of the new
  syntax.
* testing/examples/babel.org: Updated to make use of the new syntax.
* testing/examples/ob-awk-test.org: Updated to make use of the new
  syntax.
* testing/examples/ob-fortran-test.org: Updated to make use of the new
  syntax.
* testing/lisp/test-ob.el: Removed two bad tests which tested the
  literal values of old regular expressions rather than their
  behavior.
---
 contrib/babel/library-of-babel.org   |   48 +++++++++++++++++-----------------
 lisp/ob-exp.el                       |    2 +-
 lisp/ob-lob.el                       |   13 +--------
 lisp/ob-ref.el                       |    5 +++
 lisp/ob-table.el                     |    2 +-
 lisp/ob.el                           |   31 ++++++++++++---------
 lisp/org.el                          |    9 ++----
 testing/examples/babel-dangerous.org |    5 +++-
 testing/examples/babel.org           |   30 ++++++++++----------
 testing/examples/ob-awk-test.org     |    4 +-
 testing/examples/ob-fortran-test.org |    4 +-
 testing/lisp/test-ob.el              |   42 -----------------------------
 12 files changed, 77 insertions(+), 118 deletions(-)

diff --git a/contrib/babel/library-of-babel.org b/contrib/babel/library-of-babel.org
index 2db9d4c..571eb70 100644
--- a/contrib/babel/library-of-babel.org
+++ b/contrib/babel/library-of-babel.org
@@ -22,7 +22,7 @@
 
 A collection of simple utility functions:
 
-#+srcname: echo
+#+name: echo
 #+begin_src emacs-lisp :var input="echo'd"
   input
 #+end_src
@@ -35,7 +35,7 @@ Read the contents of the file at =file=.  The =:results vector= and
 =:results scalar= header arguments can be used to read the contents of
 file as either a table or a string.
 
-#+srcname: read
+#+name: read
 #+begin_src emacs-lisp :var file="" :var format=""
   (if (string= format "csv")
       (with-temp-buffer
@@ -49,7 +49,7 @@ file as either a table or a string.
 Write =data= to a file at =file=.  If =data= is a list, then write it
 as a table in traditional Org-mode table syntax.
 
-#+srcname: write
+#+name: write
 #+begin_src emacs-lisp :var data="" :var file="" :var ext='()
   (flet ((echo (r) (if (stringp r) r (format "%S" r))))
     (with-temp-file file
@@ -67,7 +67,7 @@ as a table in traditional Org-mode table syntax.
 
 Read local or remote file in [[http://www.json.org/][json]] format into emacs-lisp objects.
 
-#+srcname: json
+#+name: json
 #+begin_src emacs-lisp :var file='() :var url='()
   (require 'json)
   (cond
@@ -96,7 +96,7 @@ The =google= command seems to be throwing "Moved Temporarily" errors
 when trying to download textual documents, but this is working fine
 for spreadsheets.
 
-#+source: gdoc-read
+#+name: gdoc-read
 #+begin_src emacs-lisp :var title="example" :var format="csv"
   (let* ((file (concat title "." format))
          (cmd (format "google docs get --format %S --title %S" format title)))
@@ -126,7 +126,7 @@ Write =data= to a google document named =title=.  If =data= is tabular
 it will be saved to a spreadsheet, otherwise it will be saved as a
 normal document.
 
-#+source: gdoc-write
+#+name: gdoc-write
 #+begin_src emacs-lisp :var title="babel-upload" :var data=fibs(n=10) :results silent
   (let* ((format (if (listp data) "csv" "txt"))
          (tmp-file (make-temp-file "org-babel-google-doc" nil (concat "." format)))
@@ -157,7 +157,7 @@ example usage
   Plot column 2 (y axis) against column 1 (x axis). Columns 3 and
   beyond, if present, are ignored.
 
-#+srcname: R-plot(data=R-plot-example-data)
+#+name: R-plot(data=R-plot-example-data)
 #+begin_src R
 plot(data)
 #+end_src
@@ -169,7 +169,7 @@ plot(data)
 | 4 | 16 |
 | 5 | 25 |
 
-#+lob: R-plot(data=R-plot-example-data)
+#+call: R-plot(data=R-plot-example-data)
 
 #+resname: R-plot(data=R-plot-example-data)
 : nil
@@ -180,7 +180,7 @@ plot(data)
 
 ** Headline references
 
-#+source: headline
+#+name: headline
 #+begin_src emacs-lisp :var headline=top :var file='()
   (save-excursion
     (when file (get-file-buffer file))
@@ -217,7 +217,7 @@ optional.
 | env   | optional environment, default to "tabular" |
 | width | optional width specification string        |
 
-#+srcname: booktabs
+#+name: booktabs
 #+begin_src emacs-lisp :var table='((:head) hline (:body)) :var align='() :var env="tabular" :var width='() :noweb yes :results latex
   (flet ((to-tab (tab)
                  (orgtbl-to-generic
@@ -266,7 +266,7 @@ are optional.
 | foot      | optional "foot" string                                      |
 | lastfoot  | optional "lastfoot" string                                  |
 
-#+srcname: longtable
+#+name: longtable
 #+begin_src emacs-lisp :var table='((:table)) :var align='() :var width='() :var hline="\\hline" :var firsthead='() :var head='() :var foot='() :var lastfoot='() :noweb yes :results latex
   (org-fill-template
    "
@@ -314,7 +314,7 @@ span. Note the use of LaTeX, rather than Org-mode, markup.
 #+tblname: arguments-notes
 | \multicolumn{2}{l}{This is a footnote to the \emph{arguments} table.} |
 
-#+srcname: booktabs-notes
+#+name: booktabs-notes
 #+begin_src emacs-lisp :var table='((:head) hline (:body)) :var notes='() :var align='() :var env="tabular" :var width='() :var lspace='() :noweb yes :results latex
   (flet ((to-tab (tab)
                  (orgtbl-to-generic
@@ -356,7 +356,7 @@ span. Note the use of LaTeX, rather than Org-mode, markup.
 | 1 | 2 | 3 |
 | 4 | 5 | 6 |
 
-#+srcname: transpose
+#+name: transpose
 #+begin_src emacs-lisp :var table=transpose-example
   (apply #'mapcar* #'list table)
 #+end_src
@@ -372,7 +372,7 @@ span. Note the use of LaTeX, rather than Org-mode, markup.
 | 1 | 2 | 3 |
 | a | b | c |
 
-#+source: all-to-string
+#+name: all-to-string
 #+begin_src emacs-lisp :var tbl='()
   (defun all-to-string (tbl)
     (if (listp tbl)
@@ -387,7 +387,7 @@ span. Note the use of LaTeX, rather than Org-mode, markup.
   (mapcar (lambda (row) (mapcar (lambda (cell) (stringp cell)) row)) tbl)
 #+end_src
 
-#+results:
+#+name:
 | nil | nil | nil |
 | t   | t   | t   |
 
@@ -395,7 +395,7 @@ span. Note the use of LaTeX, rather than Org-mode, markup.
   (mapcar (lambda (row) (mapcar (lambda (cell) (stringp cell)) row)) tbl)
 #+end_src
 
-#+results:
+#+name:
 | t | t | t |
 | t | t | t |
 
@@ -412,7 +412,7 @@ export. The function uses the Emacs VC commands to interface to the
 local version control system, but has only been tested to work with
 Git. 'limit' is currently unsupported.
 
-#+source: vc-log
+#+name: vc-log
 #+headers: :var limit=-1
 #+headers: :var buf=(buffer-name (current-buffer))
 #+begin_src emacs-lisp
@@ -440,34 +440,34 @@ Git. 'limit' is currently unsupported.
 
 ** Trivial python code blocks
 
-#+srcname: python-identity(a=1)
+#+name: python-identity(a=1)
 #+begin_src python
 a
 #+end_src
 
-#+srcname: python-add(a=1, b=2)
+#+name: python-add(a=1, b=2)
 #+begin_src python
 a + b
 #+end_src
 
 ** Arithmetic
 
-#+source: lob-add
+#+name: lob-add
 #+begin_src emacs-lisp :var a=0 :var b=0
   (+ a b)
 #+end_src
 
-#+source: lob-minus
+#+name: lob-minus
 #+begin_src emacs-lisp :var a=0 :var b=0
   (- a b)
 #+end_src
 
-#+source: lob-times
+#+name: lob-times
 #+begin_src emacs-lisp :var a=0 :var b=0
   (* a b)
 #+end_src
 
-#+source: lob-div
+#+name: lob-div
 #+begin_src emacs-lisp :var a=0 :var b=0
   (/ a b)
 #+end_src
@@ -477,7 +477,7 @@ a + b
 The =elispgantt= source block was sent to the mailing list by Eric
 Fraga.  It was modified slightly by Tom Dye.
  
-#+source: elispgantt
+#+name: elispgantt
 #+begin_src emacs-lisp :var table=gantttest
   (let ((dates "")
         (entries (nthcdr 2 table))
diff --git a/lisp/ob-exp.el b/lisp/ob-exp.el
index 3b102e1..e4fae80 100644
--- a/lisp/ob-exp.el
+++ b/lisp/ob-exp.el
@@ -147,7 +147,7 @@ options and are taken from `org-babel-default-inline-header-args'."
 		(forward-char 2)))))))))
 
 (defun org-exp-res/src-name-cleanup ()
-  "Clean up #+results and #+srcname lines for export.
+  "Clean up #+results and #+name lines for export.
 This function should only be called after all block processing
 has taken place."
   (interactive)
diff --git a/lisp/ob-lob.el b/lisp/ob-lob.el
index be3033e..73f9553 100644
--- a/lisp/ob-lob.el
+++ b/lisp/ob-lob.el
@@ -61,24 +61,15 @@ To add files to this list use the `org-babel-lob-ingest' command."
 	     lob-ingest-count (if (> lob-ingest-count 1) "s" ""))
     lob-ingest-count))
 
-(defconst org-babel-lob-call-aliases '("lob" "call")
-  "Aliases to call a source block function.
-If you change the value of this variable then your files may
-  become unusable by other org-babel users, and vice versa.")
-
 (defconst org-babel-block-lob-one-liner-regexp
   (concat
-   "^\\([ \t]*\\)#\\+\\(?:"
-   (mapconcat #'regexp-quote org-babel-lob-call-aliases "\\|")
-   "\\):[ \t]+\\([^\(\)\n]+?\\)\\(\\[\\(.*\\)\\]\\|\\(\\)\\)"
+   "^\\([ \t]*\\)#\\+call:[ \t]+\\([^\(\)\n]+?\\)\\(\\[\\(.*\\)\\]\\|\\(\\)\\)"
    "\(\\([^\n]*\\)\)\\(\\[.+\\]\\|\\)[ \t]*\\(\\([^\n]*\\)\\)?")
   "Regexp to match non-inline calls to predefined source block functions.")
 
 (defconst org-babel-inline-lob-one-liner-regexp
   (concat
-   "\\([^\n]*\\)\\(?:"
-   (mapconcat #'regexp-quote org-babel-lob-call-aliases "\\|")
-   "\\)_\\([^\(\)\n]+?\\)\\(\\[\\(.*\\)\\]\\|\\(\\)\\)"
+   "\\([^\n]*\\)call_\\([^\(\)\n]+?\\)\\(\\[\\(.*\\)\\]\\|\\(\\)\\)"
    "\(\\([^\n]*\\)\)\\(\\[\\(.*?\\)\\]\\)?")
   "Regexp to match inline calls to predefined source block functions.")
 
diff --git a/lisp/ob-ref.el b/lisp/ob-ref.el
index bff3b3f..9534aac 100644
--- a/lisp/ob-ref.el
+++ b/lisp/ob-ref.el
@@ -173,6 +173,11 @@ the variable."
 	(cond
 	 (lob-info (setq type 'lob))
 	 (id (setq type 'id))
+	 ((and (looking-at org-babel-src-name-regexp)
+	       (progn (forward-line 1)
+		      (or (looking-at org-babel-src-block-regexp)
+			  (looking-at org-babel-multi-line-header-regexp))))
+	  (setq type 'source-block))
 	 (t (while (not (setq type (org-babel-ref-at-ref-p)))
 	      (forward-line 1)
 	      (beginning-of-line)
diff --git a/lisp/ob-table.el b/lisp/ob-table.el
index 1cee16e..15ebff9 100644
--- a/lisp/ob-table.el
+++ b/lisp/ob-table.el
@@ -30,7 +30,7 @@
 ;;   (defun fibbd (n) (if (< n 2) 1 (+ (fibbd (- n 1)) (fibbd (- n 2)))))
 ;; #+end_src
 
-;; #+srcname: fibbd
+;; #+name: fibbd
 ;; #+begin_src emacs-lisp :var n=2 :results silent
 ;; (fibbd n)
 ;; #+end_src
diff --git a/lisp/ob.el b/lisp/ob.el
index 4438ee8..7fd684b 100644
--- a/lisp/ob.el
+++ b/lisp/ob.el
@@ -113,7 +113,7 @@ remove code block execution from the C-c C-c keybinding."
   :type 'boolean)
 
 (defvar org-babel-src-name-regexp
-  "^[ \t]*#\\+\\(srcname\\|source\\|function\\):[ \t]*"
+  "^[ \t]*#\\+name:[ \t]*"
   "Regular expression used to match a source name line.")
 
 (defvar org-babel-multi-line-header-regexp
@@ -216,8 +216,8 @@ Returns a list
 		   (nth 2 info)
 		   (org-babel-parse-header-arguments (match-string 1)))))
 	  (when (looking-at org-babel-src-name-w-name-regexp)
-	    (setq name (org-babel-clean-text-properties (match-string 4)))
-	    (when (match-string 6)
+	    (setq name (org-babel-clean-text-properties (match-string 3)))
+	    (when (match-string 5)
 	      (setf (nth 2 info) ;; merge functional-syntax vars and header-args
 		    (org-babel-merge-params
 		     (mapcar
@@ -229,7 +229,7 @@ Returns a list
 			   (error
 			    "variable \"%s\"%s must be assigned a default value"
 			    var (if name (format " in block \"%s\"" name) ""))))
-		       (org-babel-ref-split-args (match-string 6))))
+		       (org-babel-ref-split-args (match-string 5))))
 		     (nth 2 info))))))
       ;; inline source block
       (when (org-babel-get-inline-src-block-matches)
@@ -396,7 +396,7 @@ specific header arguments as well.")
   '((:session . "none") (:results . "replace") (:exports . "results"))
   "Default arguments to use when evaluating an inline source block.")
 
-(defvar org-babel-data-names '("TBLNAME" "RESNAME" "RESULTS" "DATA"))
+(defvar org-babel-data-names '("TBLNAME" "RESULTS" "NAME"))
 
 (defvar org-babel-result-regexp
   (concat "^[ \t]*#\\+"
@@ -1359,7 +1359,7 @@ org-babel-named-src-block-regexp."
 	  (regexp (org-babel-named-src-block-regexp-for-name name)) msg)
       (goto-char (point-min))
       (when (or (re-search-forward regexp nil t)
-                (re-search-backward regexp nil t))
+		(re-search-backward regexp nil t))
         (match-beginning 0)))))
 
 (defun org-babel-src-block-names (&optional file)
@@ -1368,7 +1368,7 @@ org-babel-named-src-block-regexp."
     (when file (find-file file)) (goto-char (point-min))
     (let (names)
       (while (re-search-forward org-babel-src-name-w-name-regexp nil t)
-	(setq names (cons (match-string 4) names)))
+	(setq names (cons (match-string 3) names)))
       names)))
 
 ;;;###autoload
@@ -1384,16 +1384,21 @@ org-babel-named-src-block-regexp."
         (progn (goto-char point) (org-show-context))
       (message "result '%s' not found in this buffer" name))))
 
-(defun org-babel-find-named-result (name)
+(defun org-babel-find-named-result (name &optional point)
   "Find a named result.
 Return the location of the result named NAME in the current
 buffer or nil if no such result exists."
   (save-excursion
-    (goto-char (point-min))
-    (when (re-search-forward
-           (concat org-babel-result-regexp
-                   "[ \t]" (regexp-quote name) "[ \t\n\f\v\r]") nil t)
-      (beginning-of-line 0) (point))))
+    (goto-char (or point (point-min)))
+    (catch 'is-a-code-block
+      (when (re-search-forward
+	     (concat org-babel-result-regexp
+		     "[ \t]" (regexp-quote name) "[ \t\n\f\v\r]") nil t)
+	(when (and (string= "name" (match-string 1))
+		   (or (looking-at org-babel-src-block-regexp)
+		       (looking-at org-babel-multi-line-header-regexp)))
+	  (throw 'is-a-code-block (org-babel-find-named-result name (point))))
+	(beginning-of-line 0) (point)))))
 
 (defun org-babel-result-names (&optional file)
   "Returns the names of results in FILE or the current buffer."
diff --git a/lisp/org.el b/lisp/org.el
index 2599d41..e23242e 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5400,9 +5400,8 @@ will be prompted for."
 	     '(font-lock-fontified t face org-meta-line))
 	    t)
 	   ((or (member dc1 '("begin:" "end:" "caption:" "label:"
-			      "orgtbl:" "tblfm:" "tblname:" "result:"
-			      "results:" "source:" "srcname:" "call:"
-			      "data:" "header:" "headers:"))
+			      "orgtbl:" "tblfm:" "tblname:" "results:"
+			      "call:" "header:" "headers:"))
 		(and (match-end 4) (equal dc3 "attr")))
 	    (add-text-properties
 	     beg (match-end 0)
@@ -10966,10 +10965,8 @@ This function can be used in a hook."
     "BEGIN_CENTER" "END_CENTER"
     "BEGIN_SRC" "END_SRC"
     "BEGIN_RESULT" "END_RESULT"
-    "SOURCE:" "SRCNAME:" "FUNCTION:"
-    "RESULTS:" "DATA:"
+    "NAME:" "RESULTS:"
     "HEADER:" "HEADERS:"
-    "BABEL:"
     "CATEGORY:" "COLUMNS:" "PROPERTY:"
     "CAPTION:" "LABEL:"
     "SETUPFILE:"
diff --git a/testing/examples/babel-dangerous.org b/testing/examples/babel-dangerous.org
index 63f9f27..8ec9fa6 100644
--- a/testing/examples/babel-dangerous.org
+++ b/testing/examples/babel-dangerous.org
@@ -9,7 +9,10 @@
 There is no default value assigned to =x= variable. This is not permitted
 anymore.
 
-#+source: carre(x)
+#+name: carre(x)
 #+begin_src python
   return x*x
 #+end_src
+
+#+name: carre
+
diff --git a/testing/examples/babel.org b/testing/examples/babel.org
index 9c61b0c..45d0171 100644
--- a/testing/examples/babel.org
+++ b/testing/examples/babel.org
@@ -6,7 +6,7 @@
   :ID:       eb1f6498-5bd9-45e0-9c56-50717053e7b7
   :END:
 
-#+source: noweb-example
+#+name: noweb-example
 #+begin_src emacs-lisp
   (message "expanded")
 #+end_src
@@ -39,7 +39,7 @@
   prop
 #+end_src
 
-#+results:
+#+name:
 : 4
 
 * excessive id links on tangling
@@ -64,7 +64,7 @@
   :ID:       f68821bc-7f49-4389-85b5-914791ee3718
   :END:
 
-#+source: four
+#+name: four
 #+begin_src emacs-lisp
   (list 1 2 3 4)
 #+end_src
@@ -73,7 +73,7 @@
   (length four)
 #+end_src
 
-#+results:
+#+name:
 : 4
 
 * multi-line header arguments
@@ -86,7 +86,7 @@
   (map 'list #'list numbers letters)
 #+end_src
 
-#+results:
+#+name:
 | 1 | a |
 | 2 | b |
 | 3 | c |
@@ -100,15 +100,15 @@
   :ID:       0d82b52d-1bb9-4916-816b-2c67c8108dbb
   :END:
 
-#+source: i-have-a-name
+#+name: i-have-a-name
 #+begin_src emacs-lisp
   42
 #+end_src
 
-#+results: 
+#+name: 
 : 42
 
-#+results: i-have-a-name
+#+name: i-have-a-name
 : 42
 
 * Pascal's Triangle -- export test
@@ -116,7 +116,7 @@
   :ID:       92518f2a-a46a-4205-a3ab-bcce1008a4bb
   :END:
 
-#+source: pascals-triangle
+#+name: pascals-triangle
 #+begin_src emacs-lisp :var n=5 :exports both
   (defun pascals-triangle (n)
     (if (= n 0)
@@ -136,7 +136,7 @@
   :ID:       6d2ff4ce-4489-4e2a-9c65-e3f71f77d975
   :END:
 
-#+source: take-sqrt
+#+name: take-sqrt
 #+begin_src emacs-lisp :var n=9
   (sqrt n)
 #+end_src
@@ -159,7 +159,7 @@ This is an inline call call_echo(input="testing")[:results vector] embedded in p
 call_echo("testing")
 call_concat(1,2,3)
 
-#+source: concat
+#+name: concat
 #+begin_src emacs-lisp :var a=0 :var b=0 :var c=0
   (format "%S%S%S" a b c)
 #+end_src
@@ -169,7 +169,7 @@ call_concat(1,2,3)
   :ID:       72ddeed3-2d17-4c7f-8192-a575d535d3fc
   :END:
 
-#+source: double
+#+name: double
 #+begin_src emacs-lisp :var it=0
   (* 2 it)
 #+end_src
@@ -214,7 +214,7 @@ src_sh{echo 3} Here is one at the beginning of a line.
   :PROPERTIES:
   :ID:       5daa4d03-e3ea-46b7-b093-62c1b7632df3
   :END:
-#+results: a-list
+#+name: a-list
 - a
 - b
 - c
@@ -298,13 +298,13 @@ src_sh{echo 2} blocks on the src_emacs-lisp{"same"} line
   echo "[[file:./cv.cls]]"
 #+end_src
 
-#+results:
+#+name:
 : [[file:./cv.cls]]
 
 #+begin_src sh :results raw scalar
    echo "[[file:./cv.cls]]"
 #+end_src
 
-#+results:
+#+name:
 [[file:./cv.cls]]
 
diff --git a/testing/examples/ob-awk-test.org b/testing/examples/ob-awk-test.org
index 7f51772..9a33bf8 100644
--- a/testing/examples/ob-awk-test.org
+++ b/testing/examples/ob-awk-test.org
@@ -20,7 +20,7 @@ Use a code block ouput as an input
 #+end_src
 
 Use input file
-#+srcname: genfile
+#+name: genfile
 #+begin_src awk  :in-file ob-awk-test.in :results silent
     $0~/[\t]*#/{
         # skip comments 
@@ -33,7 +33,7 @@ Use input file
 
 * Input data generators
 A code block to generate input stream
-#+srcname: genseq
+#+name: genseq
 #+begin_src emacs-lisp :results silent
 (print "1")
 #+end_src
diff --git a/testing/examples/ob-fortran-test.org b/testing/examples/ob-fortran-test.org
index d48ae4e..47931bf 100644
--- a/testing/examples/ob-fortran-test.org
+++ b/testing/examples/ob-fortran-test.org
@@ -5,12 +5,12 @@
   :PROPERTIES:
   :ID:       459384e8-1797-4f11-867e-dde0473ea7cc
   :END:
-#+source: hello
+#+name: hello
 #+begin_src fortran :results silent
 print *, 'Hello world'
 #+end_src
 
-#+source: fortran_parameter
+#+name: fortran_parameter
 #+begin_src fortran :results silent
 integer, parameter :: i = 10
 write (*, '(i2)') i
diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el
index 58ff756..738df52 100644
--- a/testing/lisp/test-ob.el
+++ b/testing/lisp/test-ob.el
@@ -13,36 +13,6 @@
   (require 'org-test)
   (require 'org-test-ob-consts))
 
-(ert-deftest test-org-babel/src-name-regexp ()
-  (should(equal "^[ \t]*#\\+\\(srcname\\|source\\|function\\):[ \t]*"
-		org-babel-src-name-regexp))
-  (mapcar (lambda (name) 
-	    (should (org-test-string-exact-match
-		     org-babel-src-name-regexp
-		     (concat
-		      "   \t #+"
-		      name
-		      ":    \t src-name \t blah blah blah ")))
-	    (should (string-match
-		     org-babel-src-name-regexp
-		     (concat 
-		      "#+" (upcase name)
-		      ": src-name")))
-	    ;;TODO This should fail no?
-	    (should (org-test-string-exact-match
-		     org-babel-src-name-regexp
-		     (concat
-		      "#+" name ":")))
-	    ;;TODO Check - should this pass?
-	    (should (not (org-test-string-exact-match
-			  org-babel-src-name-regexp
-			  (concat
-			   "#+" name " : src-name")))))
-	  '("srcname" "source" "function"))
-  (should (not  (org-test-string-exact-match
-		 org-babel-src-name-regexp
-		 "#+invalid-name: src-name"))))
-
 (ert-deftest test-org-babel/multi-line-header-regexp ()
   (should(equal "^[ \t]*#\\+headers?:[ \t]*\\([^\n]*\\)$"
 		org-babel-multi-line-header-regexp))
@@ -63,18 +33,6 @@
 	 org-babel-multi-line-header-regexp
 	 "   \t #+headers : blah1 blah2 blah3 \t\n\t\n blah4 blah5 blah6 \n"))))
 
-(ert-deftest test-org-babel/src-name-w-name-regexp ()
-  (should(equal
-	  (concat org-babel-src-name-regexp "\\("
-		  org-babel-multi-line-header-regexp "\\)*"
-		  "\\([^ ()\f\t\n\r\v]+\\)\\(\(\\(.*\\)\)\\|\\)")
-	  org-babel-src-name-w-name-regexp))
-  (should (org-test-string-exact-match
-	   org-babel-src-name-w-name-regexp
-	   (concat
-	    "#+srcname: src-name "
-	    "#+headers: blah1 blah2 blah3 \t\n\t\n blah4 blah5 blah6 \n"))))
-
 (ert-deftest test-org-babel/src-block-regexp ()
   (let ((test-block
 	 (concat
-- 
1.7.4.1


[-- Attachment #3: Type: text/plain, Size: 47 bytes --]


-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [RFC] Standardized code block keywords

[Nick Dokos]

Eric Schulte <schulte.eric@gmail.com> wrote:

> The attached updated patch fixes a bug in the original.
> 

Minor problem in applying:

,----
| $ git apply ~/Mail/inbox/724
| /home/nick/Mail/inbox/724:671: trailing whitespace.
| #+name: 
| /home/nick/Mail/inbox/724:599: new blank line at EOF.
| +
| warning: 2 lines add whitespace errors.
`----

Re: [RFC] Standardized code block keywords

[Eric Schulte]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

Nick Dokos <nicholas.dokos@hp.com> writes:

> Eric Schulte <schulte.eric@gmail.com> wrote:
>
>> The attached updated patch fixes a bug in the original.
>> 
>
> Minor problem in applying:
>
> ,----
> | $ git apply ~/Mail/inbox/724
> | /home/nick/Mail/inbox/724:671: trailing whitespace.
> | #+name: 
> | /home/nick/Mail/inbox/724:599: new blank line at EOF.
> | +
> | warning: 2 lines add whitespace errors.
> `----

The attached version fixes these issues, Thanks -- Eric


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-removing-code-block-results-and-call-line-synonyms-B.patch --]
[-- Type: text/x-diff, Size: 24029 bytes --]

From 0e43d59ee8d46a63f86780a502de726271bc39de Mon Sep 17 00:00:00 2001
From: Eric Schulte <schulte.eric@gmail.com>
Date: Fri, 28 Oct 2011 10:44:21 -0600
Subject: [PATCH] removing code block, results and call-line synonyms -- BREAKING CHANGE

Following a round of on-list discussion many code block synonyms have
been removed, moving forward the following syntax is valid.

- call lines are specified with #+call:
- code blocks are named with #+name:
- results are named with #+name:, however results generated by a code
  block may still be labeled with #+results:, and tables named with
  #+tblname: will be considered to be named results

The following function may be used to update an existing Org-mode
buffer to the new syntax.

  (defun update-org-buffer ()
    "Update an Org-mode buffer to the new data, code block and call line syntax."
    (interactive)
    (save-excursion
      (flet ((to-re (lst) (concat "^[ \t]*#\\+" (regexp-opt lst t)
                                  "\\(\\[\\([[:alnum:]]+\\)\\]\\)?\\:[ \t]*"))
             (update (re new)
                     (goto-char (point-min))
                     (while (re-search-forward re nil t)
                       (replace-match new nil nil nil 1))))
        (let ((old-re (to-re '("RESULTS" "DATA" "SRCNAME" "SOURCE")))
              (lob-re (to-re '("LOB")))
              (case-fold-search t))
          (update old-re "name")
          (update lob-re "call")))))

Note: If an old version of Org-mode (e.g., the one shipped with Emacs)
      is installed on your system many of the important variables will
      be pre-defined with a defvar and *will not* have their values
      automatically updated, these include the following.
      - org-babel-data-names
      - org-babel-result-regexp
      - org-babel-src-block-regexp
      - org-babel-src-name-regexp
      - org-babel-src-name-w-name-regexp
      It may be necessary to either remove the source code of older
      versions of Org-mode, or to explicitly evaluate the ob.el file.

* lisp/ob-exp.el (org-exp-res/src-name-cleanup): Updated
  Documentation.
* lisp/ob-lob.el (org-babel-block-lob-one-liner-regexp): Updated
  regular expression.
  (org-babel-inline-lob-one-liner-regexp): Updated regular expression.
* lisp/ob-ref.el (org-babel-ref-resolve): Notice when something that
  looks like a data results may actually be a code block.
* lisp/ob-table.el: Updated documentation.
* lisp/ob.el (org-babel-src-name-regexp): Simplified regexp.
  (org-babel-get-src-block-info): Updated match strings.
  (org-babel-data-names): Simplified acceptable names.
  (org-babel-find-named-block): Indentation.
  (org-babel-find-named-result): Updated to not return a code block as
  a result.
* lisp/org.el (org-fontify-meta-lines-and-blocks-1): Removing
  references to old syntactic elements.
  (org-additional-option-like-keywords): Removing references to old
  syntactic elements.
* contrib/babel/library-of-babel.org: Updated to make use of the new
  syntax.
* testing/examples/babel-dangerous.org: Updated to make use of the new
  syntax.
* testing/examples/babel.org: Updated to make use of the new syntax.
* testing/examples/ob-awk-test.org: Updated to make use of the new
  syntax.
* testing/examples/ob-fortran-test.org: Updated to make use of the new
  syntax.
* testing/lisp/test-ob.el: Removed two bad tests which tested the
  literal values of old regular expressions rather than their
  behavior.
---
 contrib/babel/library-of-babel.org   |   48 +++++++++++++++++-----------------
 lisp/ob-exp.el                       |    2 +-
 lisp/ob-lob.el                       |   13 +--------
 lisp/ob-ref.el                       |    5 +++
 lisp/ob-table.el                     |    2 +-
 lisp/ob.el                           |   31 ++++++++++++---------
 lisp/org.el                          |    9 ++----
 testing/examples/babel-dangerous.org |    5 +++-
 testing/examples/babel.org           |   30 ++++++++++----------
 testing/examples/ob-awk-test.org     |    4 +-
 testing/examples/ob-fortran-test.org |    4 +-
 testing/lisp/test-ob.el              |   42 -----------------------------
 12 files changed, 77 insertions(+), 118 deletions(-)

diff --git a/contrib/babel/library-of-babel.org b/contrib/babel/library-of-babel.org
index 2db9d4c..571eb70 100644
--- a/contrib/babel/library-of-babel.org
+++ b/contrib/babel/library-of-babel.org
@@ -22,7 +22,7 @@
 
 A collection of simple utility functions:
 
-#+srcname: echo
+#+name: echo
 #+begin_src emacs-lisp :var input="echo'd"
   input
 #+end_src
@@ -35,7 +35,7 @@ Read the contents of the file at =file=.  The =:results vector= and
 =:results scalar= header arguments can be used to read the contents of
 file as either a table or a string.
 
-#+srcname: read
+#+name: read
 #+begin_src emacs-lisp :var file="" :var format=""
   (if (string= format "csv")
       (with-temp-buffer
@@ -49,7 +49,7 @@ file as either a table or a string.
 Write =data= to a file at =file=.  If =data= is a list, then write it
 as a table in traditional Org-mode table syntax.
 
-#+srcname: write
+#+name: write
 #+begin_src emacs-lisp :var data="" :var file="" :var ext='()
   (flet ((echo (r) (if (stringp r) r (format "%S" r))))
     (with-temp-file file
@@ -67,7 +67,7 @@ as a table in traditional Org-mode table syntax.
 
 Read local or remote file in [[http://www.json.org/][json]] format into emacs-lisp objects.
 
-#+srcname: json
+#+name: json
 #+begin_src emacs-lisp :var file='() :var url='()
   (require 'json)
   (cond
@@ -96,7 +96,7 @@ The =google= command seems to be throwing "Moved Temporarily" errors
 when trying to download textual documents, but this is working fine
 for spreadsheets.
 
-#+source: gdoc-read
+#+name: gdoc-read
 #+begin_src emacs-lisp :var title="example" :var format="csv"
   (let* ((file (concat title "." format))
          (cmd (format "google docs get --format %S --title %S" format title)))
@@ -126,7 +126,7 @@ Write =data= to a google document named =title=.  If =data= is tabular
 it will be saved to a spreadsheet, otherwise it will be saved as a
 normal document.
 
-#+source: gdoc-write
+#+name: gdoc-write
 #+begin_src emacs-lisp :var title="babel-upload" :var data=fibs(n=10) :results silent
   (let* ((format (if (listp data) "csv" "txt"))
          (tmp-file (make-temp-file "org-babel-google-doc" nil (concat "." format)))
@@ -157,7 +157,7 @@ example usage
   Plot column 2 (y axis) against column 1 (x axis). Columns 3 and
   beyond, if present, are ignored.
 
-#+srcname: R-plot(data=R-plot-example-data)
+#+name: R-plot(data=R-plot-example-data)
 #+begin_src R
 plot(data)
 #+end_src
@@ -169,7 +169,7 @@ plot(data)
 | 4 | 16 |
 | 5 | 25 |
 
-#+lob: R-plot(data=R-plot-example-data)
+#+call: R-plot(data=R-plot-example-data)
 
 #+resname: R-plot(data=R-plot-example-data)
 : nil
@@ -180,7 +180,7 @@ plot(data)
 
 ** Headline references
 
-#+source: headline
+#+name: headline
 #+begin_src emacs-lisp :var headline=top :var file='()
   (save-excursion
     (when file (get-file-buffer file))
@@ -217,7 +217,7 @@ optional.
 | env   | optional environment, default to "tabular" |
 | width | optional width specification string        |
 
-#+srcname: booktabs
+#+name: booktabs
 #+begin_src emacs-lisp :var table='((:head) hline (:body)) :var align='() :var env="tabular" :var width='() :noweb yes :results latex
   (flet ((to-tab (tab)
                  (orgtbl-to-generic
@@ -266,7 +266,7 @@ are optional.
 | foot      | optional "foot" string                                      |
 | lastfoot  | optional "lastfoot" string                                  |
 
-#+srcname: longtable
+#+name: longtable
 #+begin_src emacs-lisp :var table='((:table)) :var align='() :var width='() :var hline="\\hline" :var firsthead='() :var head='() :var foot='() :var lastfoot='() :noweb yes :results latex
   (org-fill-template
    "
@@ -314,7 +314,7 @@ span. Note the use of LaTeX, rather than Org-mode, markup.
 #+tblname: arguments-notes
 | \multicolumn{2}{l}{This is a footnote to the \emph{arguments} table.} |
 
-#+srcname: booktabs-notes
+#+name: booktabs-notes
 #+begin_src emacs-lisp :var table='((:head) hline (:body)) :var notes='() :var align='() :var env="tabular" :var width='() :var lspace='() :noweb yes :results latex
   (flet ((to-tab (tab)
                  (orgtbl-to-generic
@@ -356,7 +356,7 @@ span. Note the use of LaTeX, rather than Org-mode, markup.
 | 1 | 2 | 3 |
 | 4 | 5 | 6 |
 
-#+srcname: transpose
+#+name: transpose
 #+begin_src emacs-lisp :var table=transpose-example
   (apply #'mapcar* #'list table)
 #+end_src
@@ -372,7 +372,7 @@ span. Note the use of LaTeX, rather than Org-mode, markup.
 | 1 | 2 | 3 |
 | a | b | c |
 
-#+source: all-to-string
+#+name: all-to-string
 #+begin_src emacs-lisp :var tbl='()
   (defun all-to-string (tbl)
     (if (listp tbl)
@@ -387,7 +387,7 @@ span. Note the use of LaTeX, rather than Org-mode, markup.
   (mapcar (lambda (row) (mapcar (lambda (cell) (stringp cell)) row)) tbl)
 #+end_src
 
-#+results:
+#+name:
 | nil | nil | nil |
 | t   | t   | t   |
 
@@ -395,7 +395,7 @@ span. Note the use of LaTeX, rather than Org-mode, markup.
   (mapcar (lambda (row) (mapcar (lambda (cell) (stringp cell)) row)) tbl)
 #+end_src
 
-#+results:
+#+name:
 | t | t | t |
 | t | t | t |
 
@@ -412,7 +412,7 @@ export. The function uses the Emacs VC commands to interface to the
 local version control system, but has only been tested to work with
 Git. 'limit' is currently unsupported.
 
-#+source: vc-log
+#+name: vc-log
 #+headers: :var limit=-1
 #+headers: :var buf=(buffer-name (current-buffer))
 #+begin_src emacs-lisp
@@ -440,34 +440,34 @@ Git. 'limit' is currently unsupported.
 
 ** Trivial python code blocks
 
-#+srcname: python-identity(a=1)
+#+name: python-identity(a=1)
 #+begin_src python
 a
 #+end_src
 
-#+srcname: python-add(a=1, b=2)
+#+name: python-add(a=1, b=2)
 #+begin_src python
 a + b
 #+end_src
 
 ** Arithmetic
 
-#+source: lob-add
+#+name: lob-add
 #+begin_src emacs-lisp :var a=0 :var b=0
   (+ a b)
 #+end_src
 
-#+source: lob-minus
+#+name: lob-minus
 #+begin_src emacs-lisp :var a=0 :var b=0
   (- a b)
 #+end_src
 
-#+source: lob-times
+#+name: lob-times
 #+begin_src emacs-lisp :var a=0 :var b=0
   (* a b)
 #+end_src
 
-#+source: lob-div
+#+name: lob-div
 #+begin_src emacs-lisp :var a=0 :var b=0
   (/ a b)
 #+end_src
@@ -477,7 +477,7 @@ a + b
 The =elispgantt= source block was sent to the mailing list by Eric
 Fraga.  It was modified slightly by Tom Dye.
  
-#+source: elispgantt
+#+name: elispgantt
 #+begin_src emacs-lisp :var table=gantttest
   (let ((dates "")
         (entries (nthcdr 2 table))
diff --git a/lisp/ob-exp.el b/lisp/ob-exp.el
index 3b102e1..e4fae80 100644
--- a/lisp/ob-exp.el
+++ b/lisp/ob-exp.el
@@ -147,7 +147,7 @@ options and are taken from `org-babel-default-inline-header-args'."
 		(forward-char 2)))))))))
 
 (defun org-exp-res/src-name-cleanup ()
-  "Clean up #+results and #+srcname lines for export.
+  "Clean up #+results and #+name lines for export.
 This function should only be called after all block processing
 has taken place."
   (interactive)
diff --git a/lisp/ob-lob.el b/lisp/ob-lob.el
index be3033e..73f9553 100644
--- a/lisp/ob-lob.el
+++ b/lisp/ob-lob.el
@@ -61,24 +61,15 @@ To add files to this list use the `org-babel-lob-ingest' command."
 	     lob-ingest-count (if (> lob-ingest-count 1) "s" ""))
     lob-ingest-count))
 
-(defconst org-babel-lob-call-aliases '("lob" "call")
-  "Aliases to call a source block function.
-If you change the value of this variable then your files may
-  become unusable by other org-babel users, and vice versa.")
-
 (defconst org-babel-block-lob-one-liner-regexp
   (concat
-   "^\\([ \t]*\\)#\\+\\(?:"
-   (mapconcat #'regexp-quote org-babel-lob-call-aliases "\\|")
-   "\\):[ \t]+\\([^\(\)\n]+?\\)\\(\\[\\(.*\\)\\]\\|\\(\\)\\)"
+   "^\\([ \t]*\\)#\\+call:[ \t]+\\([^\(\)\n]+?\\)\\(\\[\\(.*\\)\\]\\|\\(\\)\\)"
    "\(\\([^\n]*\\)\)\\(\\[.+\\]\\|\\)[ \t]*\\(\\([^\n]*\\)\\)?")
   "Regexp to match non-inline calls to predefined source block functions.")
 
 (defconst org-babel-inline-lob-one-liner-regexp
   (concat
-   "\\([^\n]*\\)\\(?:"
-   (mapconcat #'regexp-quote org-babel-lob-call-aliases "\\|")
-   "\\)_\\([^\(\)\n]+?\\)\\(\\[\\(.*\\)\\]\\|\\(\\)\\)"
+   "\\([^\n]*\\)call_\\([^\(\)\n]+?\\)\\(\\[\\(.*\\)\\]\\|\\(\\)\\)"
    "\(\\([^\n]*\\)\)\\(\\[\\(.*?\\)\\]\\)?")
   "Regexp to match inline calls to predefined source block functions.")
 
diff --git a/lisp/ob-ref.el b/lisp/ob-ref.el
index bff3b3f..9534aac 100644
--- a/lisp/ob-ref.el
+++ b/lisp/ob-ref.el
@@ -173,6 +173,11 @@ the variable."
 	(cond
 	 (lob-info (setq type 'lob))
 	 (id (setq type 'id))
+	 ((and (looking-at org-babel-src-name-regexp)
+	       (progn (forward-line 1)
+		      (or (looking-at org-babel-src-block-regexp)
+			  (looking-at org-babel-multi-line-header-regexp))))
+	  (setq type 'source-block))
 	 (t (while (not (setq type (org-babel-ref-at-ref-p)))
 	      (forward-line 1)
 	      (beginning-of-line)
diff --git a/lisp/ob-table.el b/lisp/ob-table.el
index 1cee16e..15ebff9 100644
--- a/lisp/ob-table.el
+++ b/lisp/ob-table.el
@@ -30,7 +30,7 @@
 ;;   (defun fibbd (n) (if (< n 2) 1 (+ (fibbd (- n 1)) (fibbd (- n 2)))))
 ;; #+end_src
 
-;; #+srcname: fibbd
+;; #+name: fibbd
 ;; #+begin_src emacs-lisp :var n=2 :results silent
 ;; (fibbd n)
 ;; #+end_src
diff --git a/lisp/ob.el b/lisp/ob.el
index 4438ee8..7fd684b 100644
--- a/lisp/ob.el
+++ b/lisp/ob.el
@@ -113,7 +113,7 @@ remove code block execution from the C-c C-c keybinding."
   :type 'boolean)
 
 (defvar org-babel-src-name-regexp
-  "^[ \t]*#\\+\\(srcname\\|source\\|function\\):[ \t]*"
+  "^[ \t]*#\\+name:[ \t]*"
   "Regular expression used to match a source name line.")
 
 (defvar org-babel-multi-line-header-regexp
@@ -216,8 +216,8 @@ Returns a list
 		   (nth 2 info)
 		   (org-babel-parse-header-arguments (match-string 1)))))
 	  (when (looking-at org-babel-src-name-w-name-regexp)
-	    (setq name (org-babel-clean-text-properties (match-string 4)))
-	    (when (match-string 6)
+	    (setq name (org-babel-clean-text-properties (match-string 3)))
+	    (when (match-string 5)
 	      (setf (nth 2 info) ;; merge functional-syntax vars and header-args
 		    (org-babel-merge-params
 		     (mapcar
@@ -229,7 +229,7 @@ Returns a list
 			   (error
 			    "variable \"%s\"%s must be assigned a default value"
 			    var (if name (format " in block \"%s\"" name) ""))))
-		       (org-babel-ref-split-args (match-string 6))))
+		       (org-babel-ref-split-args (match-string 5))))
 		     (nth 2 info))))))
       ;; inline source block
       (when (org-babel-get-inline-src-block-matches)
@@ -396,7 +396,7 @@ specific header arguments as well.")
   '((:session . "none") (:results . "replace") (:exports . "results"))
   "Default arguments to use when evaluating an inline source block.")
 
-(defvar org-babel-data-names '("TBLNAME" "RESNAME" "RESULTS" "DATA"))
+(defvar org-babel-data-names '("TBLNAME" "RESULTS" "NAME"))
 
 (defvar org-babel-result-regexp
   (concat "^[ \t]*#\\+"
@@ -1359,7 +1359,7 @@ org-babel-named-src-block-regexp."
 	  (regexp (org-babel-named-src-block-regexp-for-name name)) msg)
       (goto-char (point-min))
       (when (or (re-search-forward regexp nil t)
-                (re-search-backward regexp nil t))
+		(re-search-backward regexp nil t))
         (match-beginning 0)))))
 
 (defun org-babel-src-block-names (&optional file)
@@ -1368,7 +1368,7 @@ org-babel-named-src-block-regexp."
     (when file (find-file file)) (goto-char (point-min))
     (let (names)
       (while (re-search-forward org-babel-src-name-w-name-regexp nil t)
-	(setq names (cons (match-string 4) names)))
+	(setq names (cons (match-string 3) names)))
       names)))
 
 ;;;###autoload
@@ -1384,16 +1384,21 @@ org-babel-named-src-block-regexp."
         (progn (goto-char point) (org-show-context))
       (message "result '%s' not found in this buffer" name))))
 
-(defun org-babel-find-named-result (name)
+(defun org-babel-find-named-result (name &optional point)
   "Find a named result.
 Return the location of the result named NAME in the current
 buffer or nil if no such result exists."
   (save-excursion
-    (goto-char (point-min))
-    (when (re-search-forward
-           (concat org-babel-result-regexp
-                   "[ \t]" (regexp-quote name) "[ \t\n\f\v\r]") nil t)
-      (beginning-of-line 0) (point))))
+    (goto-char (or point (point-min)))
+    (catch 'is-a-code-block
+      (when (re-search-forward
+	     (concat org-babel-result-regexp
+		     "[ \t]" (regexp-quote name) "[ \t\n\f\v\r]") nil t)
+	(when (and (string= "name" (match-string 1))
+		   (or (looking-at org-babel-src-block-regexp)
+		       (looking-at org-babel-multi-line-header-regexp)))
+	  (throw 'is-a-code-block (org-babel-find-named-result name (point))))
+	(beginning-of-line 0) (point)))))
 
 (defun org-babel-result-names (&optional file)
   "Returns the names of results in FILE or the current buffer."
diff --git a/lisp/org.el b/lisp/org.el
index 2599d41..e23242e 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5400,9 +5400,8 @@ will be prompted for."
 	     '(font-lock-fontified t face org-meta-line))
 	    t)
 	   ((or (member dc1 '("begin:" "end:" "caption:" "label:"
-			      "orgtbl:" "tblfm:" "tblname:" "result:"
-			      "results:" "source:" "srcname:" "call:"
-			      "data:" "header:" "headers:"))
+			      "orgtbl:" "tblfm:" "tblname:" "results:"
+			      "call:" "header:" "headers:"))
 		(and (match-end 4) (equal dc3 "attr")))
 	    (add-text-properties
 	     beg (match-end 0)
@@ -10966,10 +10965,8 @@ This function can be used in a hook."
     "BEGIN_CENTER" "END_CENTER"
     "BEGIN_SRC" "END_SRC"
     "BEGIN_RESULT" "END_RESULT"
-    "SOURCE:" "SRCNAME:" "FUNCTION:"
-    "RESULTS:" "DATA:"
+    "NAME:" "RESULTS:"
     "HEADER:" "HEADERS:"
-    "BABEL:"
     "CATEGORY:" "COLUMNS:" "PROPERTY:"
     "CAPTION:" "LABEL:"
     "SETUPFILE:"
diff --git a/testing/examples/babel-dangerous.org b/testing/examples/babel-dangerous.org
index 63f9f27..8ec9fa6 100644
--- a/testing/examples/babel-dangerous.org
+++ b/testing/examples/babel-dangerous.org
@@ -9,7 +9,9 @@
 There is no default value assigned to =x= variable. This is not permitted
 anymore.
 
-#+source: carre(x)
+#+name: carre(x)
 #+begin_src python
   return x*x
 #+end_src
+
+#+name: carre
diff --git a/testing/examples/babel.org b/testing/examples/babel.org
index 9c61b0c..45d0171 100644
--- a/testing/examples/babel.org
+++ b/testing/examples/babel.org
@@ -6,7 +6,7 @@
   :ID:       eb1f6498-5bd9-45e0-9c56-50717053e7b7
   :END:
 
-#+source: noweb-example
+#+name: noweb-example
 #+begin_src emacs-lisp
   (message "expanded")
 #+end_src
@@ -39,7 +39,7 @@
   prop
 #+end_src
 
-#+results:
+#+name:
 : 4
 
 * excessive id links on tangling
@@ -64,7 +64,7 @@
   :ID:       f68821bc-7f49-4389-85b5-914791ee3718
   :END:
 
-#+source: four
+#+name: four
 #+begin_src emacs-lisp
   (list 1 2 3 4)
 #+end_src
@@ -73,7 +73,7 @@
   (length four)
 #+end_src
 
-#+results:
+#+name:
 : 4
 
 * multi-line header arguments
@@ -86,7 +86,7 @@
   (map 'list #'list numbers letters)
 #+end_src
 
-#+results:
+#+name:
 | 1 | a |
 | 2 | b |
 | 3 | c |
@@ -100,15 +100,15 @@
   :ID:       0d82b52d-1bb9-4916-816b-2c67c8108dbb
   :END:
 
-#+source: i-have-a-name
+#+name: i-have-a-name
 #+begin_src emacs-lisp
   42
 #+end_src
 
-#+results: 
+#+name:
 : 42
 
-#+results: i-have-a-name
+#+name: i-have-a-name
 : 42
 
 * Pascal's Triangle -- export test
@@ -116,7 +116,7 @@
   :ID:       92518f2a-a46a-4205-a3ab-bcce1008a4bb
   :END:
 
-#+source: pascals-triangle
+#+name: pascals-triangle
 #+begin_src emacs-lisp :var n=5 :exports both
   (defun pascals-triangle (n)
     (if (= n 0)
@@ -136,7 +136,7 @@
   :ID:       6d2ff4ce-4489-4e2a-9c65-e3f71f77d975
   :END:
 
-#+source: take-sqrt
+#+name: take-sqrt
 #+begin_src emacs-lisp :var n=9
   (sqrt n)
 #+end_src
@@ -159,7 +159,7 @@ This is an inline call call_echo(input="testing")[:results vector] embedded in p
 call_echo("testing")
 call_concat(1,2,3)
 
-#+source: concat
+#+name: concat
 #+begin_src emacs-lisp :var a=0 :var b=0 :var c=0
   (format "%S%S%S" a b c)
 #+end_src
@@ -169,7 +169,7 @@ call_concat(1,2,3)
   :ID:       72ddeed3-2d17-4c7f-8192-a575d535d3fc
   :END:
 
-#+source: double
+#+name: double
 #+begin_src emacs-lisp :var it=0
   (* 2 it)
 #+end_src
@@ -214,7 +214,7 @@ src_sh{echo 3} Here is one at the beginning of a line.
   :PROPERTIES:
   :ID:       5daa4d03-e3ea-46b7-b093-62c1b7632df3
   :END:
-#+results: a-list
+#+name: a-list
 - a
 - b
 - c
@@ -298,13 +298,13 @@ src_sh{echo 2} blocks on the src_emacs-lisp{"same"} line
   echo "[[file:./cv.cls]]"
 #+end_src
 
-#+results:
+#+name:
 : [[file:./cv.cls]]
 
 #+begin_src sh :results raw scalar
    echo "[[file:./cv.cls]]"
 #+end_src
 
-#+results:
+#+name:
 [[file:./cv.cls]]
 
diff --git a/testing/examples/ob-awk-test.org b/testing/examples/ob-awk-test.org
index 7f51772..9a33bf8 100644
--- a/testing/examples/ob-awk-test.org
+++ b/testing/examples/ob-awk-test.org
@@ -20,7 +20,7 @@ Use a code block ouput as an input
 #+end_src
 
 Use input file
-#+srcname: genfile
+#+name: genfile
 #+begin_src awk  :in-file ob-awk-test.in :results silent
     $0~/[\t]*#/{
         # skip comments 
@@ -33,7 +33,7 @@ Use input file
 
 * Input data generators
 A code block to generate input stream
-#+srcname: genseq
+#+name: genseq
 #+begin_src emacs-lisp :results silent
 (print "1")
 #+end_src
diff --git a/testing/examples/ob-fortran-test.org b/testing/examples/ob-fortran-test.org
index d48ae4e..47931bf 100644
--- a/testing/examples/ob-fortran-test.org
+++ b/testing/examples/ob-fortran-test.org
@@ -5,12 +5,12 @@
   :PROPERTIES:
   :ID:       459384e8-1797-4f11-867e-dde0473ea7cc
   :END:
-#+source: hello
+#+name: hello
 #+begin_src fortran :results silent
 print *, 'Hello world'
 #+end_src
 
-#+source: fortran_parameter
+#+name: fortran_parameter
 #+begin_src fortran :results silent
 integer, parameter :: i = 10
 write (*, '(i2)') i
diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el
index 58ff756..738df52 100644
--- a/testing/lisp/test-ob.el
+++ b/testing/lisp/test-ob.el
@@ -13,36 +13,6 @@
   (require 'org-test)
   (require 'org-test-ob-consts))
 
-(ert-deftest test-org-babel/src-name-regexp ()
-  (should(equal "^[ \t]*#\\+\\(srcname\\|source\\|function\\):[ \t]*"
-		org-babel-src-name-regexp))
-  (mapcar (lambda (name) 
-	    (should (org-test-string-exact-match
-		     org-babel-src-name-regexp
-		     (concat
-		      "   \t #+"
-		      name
-		      ":    \t src-name \t blah blah blah ")))
-	    (should (string-match
-		     org-babel-src-name-regexp
-		     (concat 
-		      "#+" (upcase name)
-		      ": src-name")))
-	    ;;TODO This should fail no?
-	    (should (org-test-string-exact-match
-		     org-babel-src-name-regexp
-		     (concat
-		      "#+" name ":")))
-	    ;;TODO Check - should this pass?
-	    (should (not (org-test-string-exact-match
-			  org-babel-src-name-regexp
-			  (concat
-			   "#+" name " : src-name")))))
-	  '("srcname" "source" "function"))
-  (should (not  (org-test-string-exact-match
-		 org-babel-src-name-regexp
-		 "#+invalid-name: src-name"))))
-
 (ert-deftest test-org-babel/multi-line-header-regexp ()
   (should(equal "^[ \t]*#\\+headers?:[ \t]*\\([^\n]*\\)$"
 		org-babel-multi-line-header-regexp))
@@ -63,18 +33,6 @@
 	 org-babel-multi-line-header-regexp
 	 "   \t #+headers : blah1 blah2 blah3 \t\n\t\n blah4 blah5 blah6 \n"))))
 
-(ert-deftest test-org-babel/src-name-w-name-regexp ()
-  (should(equal
-	  (concat org-babel-src-name-regexp "\\("
-		  org-babel-multi-line-header-regexp "\\)*"
-		  "\\([^ ()\f\t\n\r\v]+\\)\\(\(\\(.*\\)\)\\|\\)")
-	  org-babel-src-name-w-name-regexp))
-  (should (org-test-string-exact-match
-	   org-babel-src-name-w-name-regexp
-	   (concat
-	    "#+srcname: src-name "
-	    "#+headers: blah1 blah2 blah3 \t\n\t\n blah4 blah5 blah6 \n"))))
-
 (ert-deftest test-org-babel/src-block-regexp ()
   (let ((test-block
 	 (concat
-- 
1.7.4.1


[-- Attachment #3: Type: text/plain, Size: 47 bytes --]


-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [RFC] Standardized code block keywords

[Nick Dokos]

[-- Attachment #1: Type: text/plain, Size: 1392 bytes --]

I'm trying to add a note to Worg hacks but before I push, I use my local
org setup to publish Worg locally and take a look at it (not entirely reliable
since my org version is usually different from the real Worg one, but a
good indication of problems before they happen nevertheless). I ran into
a couple of problems. 

The first one is expected: I'm running with Eric's patch, so when
processing Worg/org-contrib/babel/examples/o18.org (Tom Dye's article on
Archaelogy in Oceania), I ran into #+srcname vs #+name problems: when
Eric's changes do go into org and the new org is used to publish Worg,
there is going to be some breakage. Actually, o18.org is the extent of
breakage that I saw, so it doesn't look too bad.

But I also ran into a second (unrelated) issue. Here's a minimal example:

--8<---------------cut here---------------start------------->8---
* Conclusion

#+begin_src latex 

#+end_src
--8<---------------cut here---------------end--------------->8---

Exporting to html gives me the attached backtrace. But the underlying reason
is easy to demonstrate: if you C-c C-c on the empty source block, you get:

,----
| * Conclusion
| 
| #+begin_src latex 
| 
| #+end_src
| 
| #+results:
| #+END_LaTeX
| #+BEGIN_LaTeX
`----

Nick

Versions:
Org-mode version 7.7 (release_7.7.485.gcfed6.dirty)
GNU Emacs 24.0.90.2 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.0) of 2011-10-27



[-- Attachment #2: backtrace --]
[-- Type: text/plain, Size: 59059 bytes --]

Debugger entered--Lisp error: (error "unbalanced begin/end_latex blocks with \"#+BEGIN_LaTeX
\"")
  signal(error ("unbalanced begin/end_latex blocks with \"#+BEGIN_LaTeX\n\""))
  error("unbalanced begin/end_%s blocks with %S" latex "#+BEGIN_LaTeX\n")
  (progn (error "unbalanced begin/end_%s blocks with %S" type (buffer-substring match-start (point))))
  (if (not (zerop balanced)) (progn (error "unbalanced begin/end_%s blocks with %S" type (buffer-substring match-start (point)))))
  (when (not (zerop balanced)) (error "unbalanced begin/end_%s blocks with %S" type (buffer-substring match-start (point))))
  (let* ((match-start (copy-marker (match-beginning 0))) (body-start (copy-marker (match-end 0))) (indentation (length (match-string 1))) (inner-re (format "[\r\n]*[ 	]*#\\+\\(begin\\|end\\)_%s" (regexp-quote (downcase (match-string 2))))) (type (intern (downcase (match-string 2)))) (headers (save-match-data (org-split-string (match-string 3) "[ 	]+"))) (balanced 1) (preserve-indent (or org-src-preserve-indentation (member "-i" headers))) match-end) (while (and (not (zerop balanced)) (re-search-forward inner-re nil t)) (if (string= (downcase (match-string 1)) "end") (decf balanced) (incf balanced))) (when (not (zerop balanced)) (error "unbalanced begin/end_%s blocks with %S" type (buffer-substring match-start (point)))) (setq match-end (copy-marker (match-end 0))) (unless preserve-indent (setq body (save-match-data (org-remove-indentation (buffer-substring body-start (match-beginning 0)))))) (unless (memq type types) (setq types (cons type types))) (save-match-data (interblock start match-start)) (when (setq func (cadr (assoc type org-export-blocks))) (let ((replacement (save-match-data (if (memq type org-export-blocks-witheld) "" (apply func body headers))))) (when replacement (delete-region match-start match-end) (goto-char match-start) (insert replacement) (unless preserve-indent (indent-code-rigidly match-start (point) indentation))))) (set-marker match-start nil) (set-marker body-start nil) (set-marker match-end nil))
  (while (re-search-forward beg-re nil t) (let* ((match-start (copy-marker (match-beginning 0))) (body-start (copy-marker (match-end 0))) (indentation (length (match-string 1))) (inner-re (format "[\r\n]*[ 	]*#\\+\\(begin\\|end\\)_%s" (regexp-quote (downcase (match-string 2))))) (type (intern (downcase (match-string 2)))) (headers (save-match-data (org-split-string (match-string 3) "[ 	]+"))) (balanced 1) (preserve-indent (or org-src-preserve-indentation (member "-i" headers))) match-end) (while (and (not (zerop balanced)) (re-search-forward inner-re nil t)) (if (string= (downcase (match-string 1)) "end") (decf balanced) (incf balanced))) (when (not (zerop balanced)) (error "unbalanced begin/end_%s blocks with %S" type (buffer-substring match-start (point)))) (setq match-end (copy-marker (match-end 0))) (unless preserve-indent (setq body (save-match-data (org-remove-indentation (buffer-substring body-start (match-beginning 0)))))) (unless (memq type types) (setq types (cons type types))) (save-match-data (interblock start match-start)) (when (setq func (cadr (assoc type org-export-blocks))) (let ((replacement (save-match-data (if ... "" ...)))) (when replacement (delete-region match-start match-end) (goto-char match-start) (insert replacement) (unless preserve-indent (indent-code-rigidly match-start (point) indentation))))) (set-marker match-start nil) (set-marker body-start nil) (set-marker match-end nil)) (setq start (point)))
  (let ((beg-re "^\\([ 	]*\\)#\\+begin_\\(\\S-+\\)[ 	]*\\(.*\\)?[\r\n]")) (while (re-search-forward beg-re nil t) (let* ((match-start (copy-marker (match-beginning 0))) (body-start (copy-marker (match-end 0))) (indentation (length (match-string 1))) (inner-re (format "[\r\n]*[ 	]*#\\+\\(begin\\|end\\)_%s" (regexp-quote (downcase ...)))) (type (intern (downcase (match-string 2)))) (headers (save-match-data (org-split-string (match-string 3) "[ 	]+"))) (balanced 1) (preserve-indent (or org-src-preserve-indentation (member "-i" headers))) match-end) (while (and (not (zerop balanced)) (re-search-forward inner-re nil t)) (if (string= (downcase (match-string 1)) "end") (decf balanced) (incf balanced))) (when (not (zerop balanced)) (error "unbalanced begin/end_%s blocks with %S" type (buffer-substring match-start (point)))) (setq match-end (copy-marker (match-end 0))) (unless preserve-indent (setq body (save-match-data (org-remove-indentation (buffer-substring body-start ...))))) (unless (memq type types) (setq types (cons type types))) (save-match-data (interblock start match-start)) (when (setq func (cadr (assoc type org-export-blocks))) (let ((replacement (save-match-data ...))) (when replacement (delete-region match-start match-end) (goto-char match-start) (insert replacement) (unless preserve-indent (indent-code-rigidly match-start ... indentation))))) (set-marker match-start nil) (set-marker body-start nil) (set-marker match-end nil)) (setq start (point))))
  (progn (fset (quote interblock) (function* (lambda (start end) (block interblock (mapcar (lambda (pair) (funcall ... start end)) org-export-interblocks))))) (goto-char (point-min)) (setq start (point)) (let ((beg-re "^\\([ 	]*\\)#\\+begin_\\(\\S-+\\)[ 	]*\\(.*\\)?[\r\n]")) (while (re-search-forward beg-re nil t) (let* ((match-start (copy-marker (match-beginning 0))) (body-start (copy-marker (match-end 0))) (indentation (length (match-string 1))) (inner-re (format "[\r\n]*[ 	]*#\\+\\(begin\\|end\\)_%s" (regexp-quote ...))) (type (intern (downcase ...))) (headers (save-match-data (org-split-string ... "[ 	]+"))) (balanced 1) (preserve-indent (or org-src-preserve-indentation (member "-i" headers))) match-end) (while (and (not (zerop balanced)) (re-search-forward inner-re nil t)) (if (string= (downcase ...) "end") (decf balanced) (incf balanced))) (when (not (zerop balanced)) (error "unbalanced begin/end_%s blocks with %S" type (buffer-substring match-start (point)))) (setq match-end (copy-marker (match-end 0))) (unless preserve-indent (setq body (save-match-data (org-remove-indentation ...)))) (unless (memq type types) (setq types (cons type types))) (save-match-data (interblock start match-start)) (when (setq func (cadr (assoc type org-export-blocks))) (let ((replacement ...)) (when replacement (delete-region match-start match-end) (goto-char match-start) (insert replacement) (unless preserve-indent ...)))) (set-marker match-start nil) (set-marker body-start nil) (set-marker match-end nil)) (setq start (point)))) (interblock start (point-max)) (run-hooks (quote org-export-blocks-postblock-hook)))
  (unwind-protect (progn (fset (quote interblock) (function* (lambda (start end) (block interblock (mapcar (lambda ... ...) org-export-interblocks))))) (goto-char (point-min)) (setq start (point)) (let ((beg-re "^\\([ 	]*\\)#\\+begin_\\(\\S-+\\)[ 	]*\\(.*\\)?[\r\n]")) (while (re-search-forward beg-re nil t) (let* ((match-start (copy-marker ...)) (body-start (copy-marker ...)) (indentation (length ...)) (inner-re (format "[\r\n]*[ 	]*#\\+\\(begin\\|end\\)_%s" ...)) (type (intern ...)) (headers (save-match-data ...)) (balanced 1) (preserve-indent (or org-src-preserve-indentation ...)) match-end) (while (and (not ...) (re-search-forward inner-re nil t)) (if (string= ... "end") (decf balanced) (incf balanced))) (when (not (zerop balanced)) (error "unbalanced begin/end_%s blocks with %S" type (buffer-substring match-start ...))) (setq match-end (copy-marker (match-end 0))) (unless preserve-indent (setq body (save-match-data ...))) (unless (memq type types) (setq types (cons type types))) (save-match-data (interblock start match-start)) (when (setq func (cadr ...)) (let (...) (when replacement ... ... ... ...))) (set-marker match-start nil) (set-marker body-start nil) (set-marker match-end nil)) (setq start (point)))) (interblock start (point-max)) (run-hooks (quote org-export-blocks-postblock-hook))) (if --cl-letf-bound-- (fset (quote interblock) --cl-letf-save--) (fmakunbound (quote interblock))))
  (let* ((--cl-letf-bound-- (fboundp (quote interblock))) (--cl-letf-save-- (and --cl-letf-bound-- (symbol-function (quote interblock))))) (unwind-protect (progn (fset (quote interblock) (function* (lambda (start end) (block interblock (mapcar ... org-export-interblocks))))) (goto-char (point-min)) (setq start (point)) (let ((beg-re "^\\([ 	]*\\)#\\+begin_\\(\\S-+\\)[ 	]*\\(.*\\)?[\r\n]")) (while (re-search-forward beg-re nil t) (let* ((match-start ...) (body-start ...) (indentation ...) (inner-re ...) (type ...) (headers ...) (balanced 1) (preserve-indent ...) match-end) (while (and ... ...) (if ... ... ...)) (when (not ...) (error "unbalanced begin/end_%s blocks with %S" type ...)) (setq match-end (copy-marker ...)) (unless preserve-indent (setq body ...)) (unless (memq type types) (setq types ...)) (save-match-data (interblock start match-start)) (when (setq func ...) (let ... ...)) (set-marker match-start nil) (set-marker body-start nil) (set-marker match-end nil)) (setq start (point)))) (interblock start (point-max)) (run-hooks (quote org-export-blocks-postblock-hook))) (if --cl-letf-bound-- (fset (quote interblock) --cl-letf-save--) (fmakunbound (quote interblock)))))
  (letf (((symbol-function (quote interblock)) (function* (lambda (start end) (block interblock (mapcar (lambda ... ...) org-export-interblocks)))))) (goto-char (point-min)) (setq start (point)) (let ((beg-re "^\\([ 	]*\\)#\\+begin_\\(\\S-+\\)[ 	]*\\(.*\\)?[\r\n]")) (while (re-search-forward beg-re nil t) (let* ((match-start (copy-marker (match-beginning 0))) (body-start (copy-marker (match-end 0))) (indentation (length (match-string 1))) (inner-re (format "[\r\n]*[ 	]*#\\+\\(begin\\|end\\)_%s" (regexp-quote ...))) (type (intern (downcase ...))) (headers (save-match-data (org-split-string ... "[ 	]+"))) (balanced 1) (preserve-indent (or org-src-preserve-indentation (member "-i" headers))) match-end) (while (and (not (zerop balanced)) (re-search-forward inner-re nil t)) (if (string= (downcase ...) "end") (decf balanced) (incf balanced))) (when (not (zerop balanced)) (error "unbalanced begin/end_%s blocks with %S" type (buffer-substring match-start (point)))) (setq match-end (copy-marker (match-end 0))) (unless preserve-indent (setq body (save-match-data (org-remove-indentation ...)))) (unless (memq type types) (setq types (cons type types))) (save-match-data (interblock start match-start)) (when (setq func (cadr (assoc type org-export-blocks))) (let ((replacement ...)) (when replacement (delete-region match-start match-end) (goto-char match-start) (insert replacement) (unless preserve-indent ...)))) (set-marker match-start nil) (set-marker body-start nil) (set-marker match-end nil)) (setq start (point)))) (interblock start (point-max)) (run-hooks (quote org-export-blocks-postblock-hook)))
  (letf* (((symbol-function (quote interblock)) (function* (lambda (start end) (block interblock (mapcar (lambda ... ...) org-export-interblocks)))))) (goto-char (point-min)) (setq start (point)) (let ((beg-re "^\\([ 	]*\\)#\\+begin_\\(\\S-+\\)[ 	]*\\(.*\\)?[\r\n]")) (while (re-search-forward beg-re nil t) (let* ((match-start (copy-marker (match-beginning 0))) (body-start (copy-marker (match-end 0))) (indentation (length (match-string 1))) (inner-re (format "[\r\n]*[ 	]*#\\+\\(begin\\|end\\)_%s" (regexp-quote ...))) (type (intern (downcase ...))) (headers (save-match-data (org-split-string ... "[ 	]+"))) (balanced 1) (preserve-indent (or org-src-preserve-indentation (member "-i" headers))) match-end) (while (and (not (zerop balanced)) (re-search-forward inner-re nil t)) (if (string= (downcase ...) "end") (decf balanced) (incf balanced))) (when (not (zerop balanced)) (error "unbalanced begin/end_%s blocks with %S" type (buffer-substring match-start (point)))) (setq match-end (copy-marker (match-end 0))) (unless preserve-indent (setq body (save-match-data (org-remove-indentation ...)))) (unless (memq type types) (setq types (cons type types))) (save-match-data (interblock start match-start)) (when (setq func (cadr (assoc type org-export-blocks))) (let ((replacement ...)) (when replacement (delete-region match-start match-end) (goto-char match-start) (insert replacement) (unless preserve-indent ...)))) (set-marker match-start nil) (set-marker body-start nil) (set-marker match-end nil)) (setq start (point)))) (interblock start (point-max)) (run-hooks (quote org-export-blocks-postblock-hook)))
  (flet ((interblock (start end) (mapcar (lambda (pair) (funcall (second pair) start end)) org-export-interblocks))) (goto-char (point-min)) (setq start (point)) (let ((beg-re "^\\([ 	]*\\)#\\+begin_\\(\\S-+\\)[ 	]*\\(.*\\)?[\r\n]")) (while (re-search-forward beg-re nil t) (let* ((match-start (copy-marker (match-beginning 0))) (body-start (copy-marker (match-end 0))) (indentation (length (match-string 1))) (inner-re (format "[\r\n]*[ 	]*#\\+\\(begin\\|end\\)_%s" (regexp-quote ...))) (type (intern (downcase ...))) (headers (save-match-data (org-split-string ... "[ 	]+"))) (balanced 1) (preserve-indent (or org-src-preserve-indentation (member "-i" headers))) match-end) (while (and (not (zerop balanced)) (re-search-forward inner-re nil t)) (if (string= (downcase ...) "end") (decf balanced) (incf balanced))) (when (not (zerop balanced)) (error "unbalanced begin/end_%s blocks with %S" type (buffer-substring match-start (point)))) (setq match-end (copy-marker (match-end 0))) (unless preserve-indent (setq body (save-match-data (org-remove-indentation ...)))) (unless (memq type types) (setq types (cons type types))) (save-match-data (interblock start match-start)) (when (setq func (cadr (assoc type org-export-blocks))) (let ((replacement ...)) (when replacement (delete-region match-start match-end) (goto-char match-start) (insert replacement) (unless preserve-indent ...)))) (set-marker match-start nil) (set-marker body-start nil) (set-marker match-end nil)) (setq start (point)))) (interblock start (point-max)) (run-hooks (quote org-export-blocks-postblock-hook)))
  (let ((case-fold-search t) (types (quote nil)) matched indentation type func start end body headers preserve-indent progress-marker) (flet ((interblock (start end) (mapcar (lambda (pair) (funcall (second pair) start end)) org-export-interblocks))) (goto-char (point-min)) (setq start (point)) (let ((beg-re "^\\([ 	]*\\)#\\+begin_\\(\\S-+\\)[ 	]*\\(.*\\)?[\r\n]")) (while (re-search-forward beg-re nil t) (let* ((match-start (copy-marker ...)) (body-start (copy-marker ...)) (indentation (length ...)) (inner-re (format "[\r\n]*[ 	]*#\\+\\(begin\\|end\\)_%s" ...)) (type (intern ...)) (headers (save-match-data ...)) (balanced 1) (preserve-indent (or org-src-preserve-indentation ...)) match-end) (while (and (not ...) (re-search-forward inner-re nil t)) (if (string= ... "end") (decf balanced) (incf balanced))) (when (not (zerop balanced)) (error "unbalanced begin/end_%s blocks with %S" type (buffer-substring match-start ...))) (setq match-end (copy-marker (match-end 0))) (unless preserve-indent (setq body (save-match-data ...))) (unless (memq type types) (setq types (cons type types))) (save-match-data (interblock start match-start)) (when (setq func (cadr ...)) (let (...) (when replacement ... ... ... ...))) (set-marker match-start nil) (set-marker body-start nil) (set-marker match-end nil)) (setq start (point)))) (interblock start (point-max)) (run-hooks (quote org-export-blocks-postblock-hook))))
  (progn (let ((case-fold-search t) (types (quote nil)) matched indentation type func start end body headers preserve-indent progress-marker) (flet ((interblock (start end) (mapcar (lambda (pair) (funcall ... start end)) org-export-interblocks))) (goto-char (point-min)) (setq start (point)) (let ((beg-re "^\\([ 	]*\\)#\\+begin_\\(\\S-+\\)[ 	]*\\(.*\\)?[\r\n]")) (while (re-search-forward beg-re nil t) (let* ((match-start ...) (body-start ...) (indentation ...) (inner-re ...) (type ...) (headers ...) (balanced 1) (preserve-indent ...) match-end) (while (and ... ...) (if ... ... ...)) (when (not ...) (error "unbalanced begin/end_%s blocks with %S" type ...)) (setq match-end (copy-marker ...)) (unless preserve-indent (setq body ...)) (unless (memq type types) (setq types ...)) (save-match-data (interblock start match-start)) (when (setq func ...) (let ... ...)) (set-marker match-start nil) (set-marker body-start nil) (set-marker match-end nil)) (setq start (point)))) (interblock start (point-max)) (run-hooks (quote org-export-blocks-postblock-hook)))))
  (unwind-protect (progn (let ((case-fold-search t) (types (quote nil)) matched indentation type func start end body headers preserve-indent progress-marker) (flet ((interblock (start end) (mapcar (lambda ... ...) org-export-interblocks))) (goto-char (point-min)) (setq start (point)) (let ((beg-re "^\\([ 	]*\\)#\\+begin_\\(\\S-+\\)[ 	]*\\(.*\\)?[\r\n]")) (while (re-search-forward beg-re nil t) (let* (... ... ... ... ... ... ... ... match-end) (while ... ...) (when ... ...) (setq match-end ...) (unless preserve-indent ...) (unless ... ...) (save-match-data ...) (when ... ...) (set-marker match-start nil) (set-marker body-start nil) (set-marker match-end nil)) (setq start (point)))) (interblock start (point-max)) (run-hooks (quote org-export-blocks-postblock-hook))))) (set-window-configuration wconfig))
  (let ((wconfig (current-window-configuration))) (unwind-protect (progn (let ((case-fold-search t) (types (quote nil)) matched indentation type func start end body headers preserve-indent progress-marker) (flet ((interblock (start end) (mapcar ... org-export-interblocks))) (goto-char (point-min)) (setq start (point)) (let ((beg-re "^\\([ 	]*\\)#\\+begin_\\(\\S-+\\)[ 	]*\\(.*\\)?[\r\n]")) (while (re-search-forward beg-re nil t) (let* ... ... ... ... ... ... ... ... ... ... ...) (setq start ...))) (interblock start (point-max)) (run-hooks (quote org-export-blocks-postblock-hook))))) (set-window-configuration wconfig)))
  (save-window-excursion (let ((case-fold-search t) (types (quote nil)) matched indentation type func start end body headers preserve-indent progress-marker) (flet ((interblock (start end) (mapcar (lambda (pair) (funcall ... start end)) org-export-interblocks))) (goto-char (point-min)) (setq start (point)) (let ((beg-re "^\\([ 	]*\\)#\\+begin_\\(\\S-+\\)[ 	]*\\(.*\\)?[\r\n]")) (while (re-search-forward beg-re nil t) (let* ((match-start ...) (body-start ...) (indentation ...) (inner-re ...) (type ...) (headers ...) (balanced 1) (preserve-indent ...) match-end) (while (and ... ...) (if ... ... ...)) (when (not ...) (error "unbalanced begin/end_%s blocks with %S" type ...)) (setq match-end (copy-marker ...)) (unless preserve-indent (setq body ...)) (unless (memq type types) (setq types ...)) (save-match-data (interblock start match-start)) (when (setq func ...) (let ... ...)) (set-marker match-start nil) (set-marker body-start nil) (set-marker match-end nil)) (setq start (point)))) (interblock start (point-max)) (run-hooks (quote org-export-blocks-postblock-hook)))))
  org-export-blocks-preprocess()
  (progn (erase-buffer) (insert string) (setq case-fold-search t) (let ((inhibit-read-only t)) (remove-text-properties (point-min) (point-max) (quote (read-only t)))) (org-export-kill-licensed-text) (let ((org-inhibit-startup t)) (org-mode)) (setq case-fold-search t) (org-clone-local-variables source-buffer "^\\(org-\\|orgtbl-\\)") (org-install-letbind) (run-hooks (quote org-export-preprocess-hook)) (untabify (point-min) (point-max)) (org-export-handle-include-files-recurse) (run-hooks (quote org-export-preprocess-after-include-files-hook)) (org-export-remove-archived-trees archived-trees) (org-export-remove-comment-blocks-and-subtrees) (org-export-handle-export-tags (plist-get parameters :select-tags) (plist-get parameters :exclude-tags)) (run-hooks (quote org-export-preprocess-after-tree-selection-hook)) (org-export-remove-tasks (plist-get parameters :tasks)) (when (plist-get parameters :footnotes) (org-footnote-normalize nil parameters)) (org-export-mark-list-end) (org-export-preprocess-apply-macros) (run-hooks (quote org-export-preprocess-after-macros-hook)) (org-export-blocks-preprocess) (org-export-mark-list-properties) (org-export-replace-src-segments-and-examples) (org-export-protect-colon-examples) (org-export-convert-protected-spaces) (setq target-alist (org-export-define-heading-targets target-alist)) (run-hooks (quote org-export-preprocess-after-headline-targets-hook)) (org-export-remember-html-container-classes) (org-export-remove-or-extract-drawers drawers (plist-get parameters :drawers)) (when (plist-get parameters :skip-before-1st-heading) (goto-char (point-min)) (when (re-search-forward "^\\(#.*\n\\)?\\*+[ 	]" nil t) (delete-region (point-min) (match-beginning 0)) (goto-char (point-min)) (insert "\n"))) (when (plist-get parameters :add-text) (goto-char (point-min)) (insert (plist-get parameters :add-text) "\n")) (org-export-remove-headline-metadata parameters) (setq target-alist (org-export-handle-invisible-targets target-alist)) (run-hooks (quote org-export-preprocess-before-selecting-backend-code-hook)) (org-export-select-backend-specific-text) (org-export-protect-quoted-subtrees) (org-export-remove-clock-lines) (org-export-protect-verbatim) (org-export-mark-blockquote-verse-center) (run-hooks (quote org-export-preprocess-after-blockquote-hook)) (unless (plist-get parameters :timestamps) (org-export-remove-timestamps)) (setq target-alist (org-export-attach-captions-and-attributes target-alist)) (org-export-mark-radio-links) (run-hooks (quote org-export-preprocess-after-radio-targets-hook)) (org-export-concatenate-multiline-links) (run-hooks (quote org-export-preprocess-before-normalizing-links-hook)) (org-export-normalize-links) ...)
  (unwind-protect (progn (erase-buffer) (insert string) (setq case-fold-search t) (let ((inhibit-read-only t)) (remove-text-properties (point-min) (point-max) (quote (read-only t)))) (org-export-kill-licensed-text) (let ((org-inhibit-startup t)) (org-mode)) (setq case-fold-search t) (org-clone-local-variables source-buffer "^\\(org-\\|orgtbl-\\)") (org-install-letbind) (run-hooks (quote org-export-preprocess-hook)) (untabify (point-min) (point-max)) (org-export-handle-include-files-recurse) (run-hooks (quote org-export-preprocess-after-include-files-hook)) (org-export-remove-archived-trees archived-trees) (org-export-remove-comment-blocks-and-subtrees) (org-export-handle-export-tags (plist-get parameters :select-tags) (plist-get parameters :exclude-tags)) (run-hooks (quote org-export-preprocess-after-tree-selection-hook)) (org-export-remove-tasks (plist-get parameters :tasks)) (when (plist-get parameters :footnotes) (org-footnote-normalize nil parameters)) (org-export-mark-list-end) (org-export-preprocess-apply-macros) (run-hooks (quote org-export-preprocess-after-macros-hook)) (org-export-blocks-preprocess) (org-export-mark-list-properties) (org-export-replace-src-segments-and-examples) (org-export-protect-colon-examples) (org-export-convert-protected-spaces) (setq target-alist (org-export-define-heading-targets target-alist)) (run-hooks (quote org-export-preprocess-after-headline-targets-hook)) (org-export-remember-html-container-classes) (org-export-remove-or-extract-drawers drawers (plist-get parameters :drawers)) (when (plist-get parameters :skip-before-1st-heading) (goto-char (point-min)) (when (re-search-forward "^\\(#.*\n\\)?\\*+[ 	]" nil t) (delete-region (point-min) (match-beginning 0)) (goto-char (point-min)) (insert "\n"))) (when (plist-get parameters :add-text) (goto-char (point-min)) (insert (plist-get parameters :add-text) "\n")) (org-export-remove-headline-metadata parameters) (setq target-alist (org-export-handle-invisible-targets target-alist)) (run-hooks (quote org-export-preprocess-before-selecting-backend-code-hook)) (org-export-select-backend-specific-text) (org-export-protect-quoted-subtrees) (org-export-remove-clock-lines) (org-export-protect-verbatim) (org-export-mark-blockquote-verse-center) (run-hooks (quote org-export-preprocess-after-blockquote-hook)) (unless (plist-get parameters :timestamps) (org-export-remove-timestamps)) (setq target-alist (org-export-attach-captions-and-attributes target-alist)) (org-export-mark-radio-links) (run-hooks (quote org-export-preprocess-after-radio-targets-hook)) (org-export-concatenate-multiline-links) (run-hooks (quote org-export-preprocess-before-normalizing-links-hook)) (org-export-normalize-links) ...) (and (buffer-name temp-buffer) (kill-buffer temp-buffer)))
  (save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn (erase-buffer) (insert string) (setq case-fold-search t) (let ((inhibit-read-only t)) (remove-text-properties (point-min) (point-max) (quote (read-only t)))) (org-export-kill-licensed-text) (let ((org-inhibit-startup t)) (org-mode)) (setq case-fold-search t) (org-clone-local-variables source-buffer "^\\(org-\\|orgtbl-\\)") (org-install-letbind) (run-hooks (quote org-export-preprocess-hook)) (untabify (point-min) (point-max)) (org-export-handle-include-files-recurse) (run-hooks (quote org-export-preprocess-after-include-files-hook)) (org-export-remove-archived-trees archived-trees) (org-export-remove-comment-blocks-and-subtrees) (org-export-handle-export-tags (plist-get parameters :select-tags) (plist-get parameters :exclude-tags)) (run-hooks (quote org-export-preprocess-after-tree-selection-hook)) (org-export-remove-tasks (plist-get parameters :tasks)) (when (plist-get parameters :footnotes) (org-footnote-normalize nil parameters)) (org-export-mark-list-end) (org-export-preprocess-apply-macros) (run-hooks (quote org-export-preprocess-after-macros-hook)) (org-export-blocks-preprocess) (org-export-mark-list-properties) (org-export-replace-src-segments-and-examples) (org-export-protect-colon-examples) (org-export-convert-protected-spaces) (setq target-alist (org-export-define-heading-targets target-alist)) (run-hooks (quote org-export-preprocess-after-headline-targets-hook)) (org-export-remember-html-container-classes) (org-export-remove-or-extract-drawers drawers (plist-get parameters :drawers)) (when (plist-get parameters :skip-before-1st-heading) (goto-char (point-min)) (when (re-search-forward "^\\(#.*\n\\)?\\*+[ 	]" nil t) (delete-region (point-min) (match-beginning 0)) (goto-char (point-min)) (insert "\n"))) (when (plist-get parameters :add-text) (goto-char (point-min)) (insert (plist-get parameters :add-text) "\n")) (org-export-remove-headline-metadata parameters) (setq target-alist (org-export-handle-invisible-targets target-alist)) (run-hooks (quote org-export-preprocess-before-selecting-backend-code-hook)) (org-export-select-backend-specific-text) (org-export-protect-quoted-subtrees) (org-export-remove-clock-lines) (org-export-protect-verbatim) (org-export-mark-blockquote-verse-center) (run-hooks (quote org-export-preprocess-after-blockquote-hook)) (unless (plist-get parameters :timestamps) (org-export-remove-timestamps)) (setq target-alist (org-export-attach-captions-and-attributes target-alist)) (org-export-mark-radio-links) (run-hooks (quote org-export-preprocess-after-radio-targets-hook)) (org-export-concatenate-multiline-links) (run-hooks (quote org-export-preprocess-before-normalizing-links-hook)) (org-export-normalize-links) ...) (and (buffer-name temp-buffer) (kill-buffer temp-buffer))))
  (with-current-buffer temp-buffer (unwind-protect (progn (erase-buffer) (insert string) (setq case-fold-search t) (let ((inhibit-read-only t)) (remove-text-properties (point-min) (point-max) (quote (read-only t)))) (org-export-kill-licensed-text) (let ((org-inhibit-startup t)) (org-mode)) (setq case-fold-search t) (org-clone-local-variables source-buffer "^\\(org-\\|orgtbl-\\)") (org-install-letbind) (run-hooks (quote org-export-preprocess-hook)) (untabify (point-min) (point-max)) (org-export-handle-include-files-recurse) (run-hooks (quote org-export-preprocess-after-include-files-hook)) (org-export-remove-archived-trees archived-trees) (org-export-remove-comment-blocks-and-subtrees) (org-export-handle-export-tags (plist-get parameters :select-tags) (plist-get parameters :exclude-tags)) (run-hooks (quote org-export-preprocess-after-tree-selection-hook)) (org-export-remove-tasks (plist-get parameters :tasks)) (when (plist-get parameters :footnotes) (org-footnote-normalize nil parameters)) (org-export-mark-list-end) (org-export-preprocess-apply-macros) (run-hooks (quote org-export-preprocess-after-macros-hook)) (org-export-blocks-preprocess) (org-export-mark-list-properties) (org-export-replace-src-segments-and-examples) (org-export-protect-colon-examples) (org-export-convert-protected-spaces) (setq target-alist (org-export-define-heading-targets target-alist)) (run-hooks (quote org-export-preprocess-after-headline-targets-hook)) (org-export-remember-html-container-classes) (org-export-remove-or-extract-drawers drawers (plist-get parameters :drawers)) (when (plist-get parameters :skip-before-1st-heading) (goto-char (point-min)) (when (re-search-forward "^\\(#.*\n\\)?\\*+[ 	]" nil t) (delete-region (point-min) (match-beginning 0)) (goto-char (point-min)) (insert "\n"))) (when (plist-get parameters :add-text) (goto-char (point-min)) (insert (plist-get parameters :add-text) "\n")) (org-export-remove-headline-metadata parameters) (setq target-alist (org-export-handle-invisible-targets target-alist)) (run-hooks (quote org-export-preprocess-before-selecting-backend-code-hook)) (org-export-select-backend-specific-text) (org-export-protect-quoted-subtrees) (org-export-remove-clock-lines) (org-export-protect-verbatim) (org-export-mark-blockquote-verse-center) (run-hooks (quote org-export-preprocess-after-blockquote-hook)) (unless (plist-get parameters :timestamps) (org-export-remove-timestamps)) (setq target-alist (org-export-attach-captions-and-attributes target-alist)) (org-export-mark-radio-links) (run-hooks (quote org-export-preprocess-after-radio-targets-hook)) (org-export-concatenate-multiline-links) (run-hooks (quote org-export-preprocess-before-normalizing-links-hook)) (org-export-normalize-links) ...) (and (buffer-name temp-buffer) (kill-buffer temp-buffer))))
  (let ((temp-buffer (generate-new-buffer " *temp*"))) (with-current-buffer temp-buffer (unwind-protect (progn (erase-buffer) (insert string) (setq case-fold-search t) (let ((inhibit-read-only t)) (remove-text-properties (point-min) (point-max) (quote (read-only t)))) (org-export-kill-licensed-text) (let ((org-inhibit-startup t)) (org-mode)) (setq case-fold-search t) (org-clone-local-variables source-buffer "^\\(org-\\|orgtbl-\\)") (org-install-letbind) (run-hooks (quote org-export-preprocess-hook)) (untabify (point-min) (point-max)) (org-export-handle-include-files-recurse) (run-hooks (quote org-export-preprocess-after-include-files-hook)) (org-export-remove-archived-trees archived-trees) (org-export-remove-comment-blocks-and-subtrees) (org-export-handle-export-tags (plist-get parameters :select-tags) (plist-get parameters :exclude-tags)) (run-hooks (quote org-export-preprocess-after-tree-selection-hook)) (org-export-remove-tasks (plist-get parameters :tasks)) (when (plist-get parameters :footnotes) (org-footnote-normalize nil parameters)) (org-export-mark-list-end) (org-export-preprocess-apply-macros) (run-hooks (quote org-export-preprocess-after-macros-hook)) (org-export-blocks-preprocess) (org-export-mark-list-properties) (org-export-replace-src-segments-and-examples) (org-export-protect-colon-examples) (org-export-convert-protected-spaces) (setq target-alist (org-export-define-heading-targets target-alist)) (run-hooks (quote org-export-preprocess-after-headline-targets-hook)) (org-export-remember-html-container-classes) (org-export-remove-or-extract-drawers drawers (plist-get parameters :drawers)) (when (plist-get parameters :skip-before-1st-heading) (goto-char (point-min)) (when (re-search-forward "^\\(#.*\n\\)?\\*+[ 	]" nil t) (delete-region (point-min) (match-beginning 0)) (goto-char (point-min)) (insert "\n"))) (when (plist-get parameters :add-text) (goto-char (point-min)) (insert (plist-get parameters :add-text) "\n")) (org-export-remove-headline-metadata parameters) (setq target-alist (org-export-handle-invisible-targets target-alist)) (run-hooks (quote org-export-preprocess-before-selecting-backend-code-hook)) (org-export-select-backend-specific-text) (org-export-protect-quoted-subtrees) (org-export-remove-clock-lines) (org-export-protect-verbatim) (org-export-mark-blockquote-verse-center) (run-hooks (quote org-export-preprocess-after-blockquote-hook)) (unless (plist-get parameters :timestamps) (org-export-remove-timestamps)) (setq target-alist (org-export-attach-captions-and-attributes target-alist)) (org-export-mark-radio-links) (run-hooks (quote org-export-preprocess-after-radio-targets-hook)) (org-export-concatenate-multiline-links) (run-hooks (quote org-export-preprocess-before-normalizing-links-hook)) (org-export-normalize-links) ...) (and (buffer-name temp-buffer) (kill-buffer temp-buffer)))))
  (with-temp-buffer (erase-buffer) (insert string) (setq case-fold-search t) (let ((inhibit-read-only t)) (remove-text-properties (point-min) (point-max) (quote (read-only t)))) (org-export-kill-licensed-text) (let ((org-inhibit-startup t)) (org-mode)) (setq case-fold-search t) (org-clone-local-variables source-buffer "^\\(org-\\|orgtbl-\\)") (org-install-letbind) (run-hooks (quote org-export-preprocess-hook)) (untabify (point-min) (point-max)) (org-export-handle-include-files-recurse) (run-hooks (quote org-export-preprocess-after-include-files-hook)) (org-export-remove-archived-trees archived-trees) (org-export-remove-comment-blocks-and-subtrees) (org-export-handle-export-tags (plist-get parameters :select-tags) (plist-get parameters :exclude-tags)) (run-hooks (quote org-export-preprocess-after-tree-selection-hook)) (org-export-remove-tasks (plist-get parameters :tasks)) (when (plist-get parameters :footnotes) (org-footnote-normalize nil parameters)) (org-export-mark-list-end) (org-export-preprocess-apply-macros) (run-hooks (quote org-export-preprocess-after-macros-hook)) (org-export-blocks-preprocess) (org-export-mark-list-properties) (org-export-replace-src-segments-and-examples) (org-export-protect-colon-examples) (org-export-convert-protected-spaces) (setq target-alist (org-export-define-heading-targets target-alist)) (run-hooks (quote org-export-preprocess-after-headline-targets-hook)) (org-export-remember-html-container-classes) (org-export-remove-or-extract-drawers drawers (plist-get parameters :drawers)) (when (plist-get parameters :skip-before-1st-heading) (goto-char (point-min)) (when (re-search-forward "^\\(#.*\n\\)?\\*+[ 	]" nil t) (delete-region (point-min) (match-beginning 0)) (goto-char (point-min)) (insert "\n"))) (when (plist-get parameters :add-text) (goto-char (point-min)) (insert (plist-get parameters :add-text) "\n")) (org-export-remove-headline-metadata parameters) (setq target-alist (org-export-handle-invisible-targets target-alist)) (run-hooks (quote org-export-preprocess-before-selecting-backend-code-hook)) (org-export-select-backend-specific-text) (org-export-protect-quoted-subtrees) (org-export-remove-clock-lines) (org-export-protect-verbatim) (org-export-mark-blockquote-verse-center) (run-hooks (quote org-export-preprocess-after-blockquote-hook)) (unless (plist-get parameters :timestamps) (org-export-remove-timestamps)) (setq target-alist (org-export-attach-captions-and-attributes target-alist)) (org-export-mark-radio-links) (run-hooks (quote org-export-preprocess-after-radio-targets-hook)) (org-export-concatenate-multiline-links) (run-hooks (quote org-export-preprocess-before-normalizing-links-hook)) (org-export-normalize-links) ...)
  (let* ((org-export-current-backend (or (plist-get parameters :for-backend) org-export-current-backend)) (archived-trees (plist-get parameters :archived-trees)) (inhibit-read-only t) (drawers org-drawers) (source-buffer (current-buffer)) target-alist rtn) (setq org-export-target-aliases nil org-export-preferred-target-alist nil org-export-id-target-alist nil org-export-code-refs nil) (with-temp-buffer (erase-buffer) (insert string) (setq case-fold-search t) (let ((inhibit-read-only t)) (remove-text-properties (point-min) (point-max) (quote (read-only t)))) (org-export-kill-licensed-text) (let ((org-inhibit-startup t)) (org-mode)) (setq case-fold-search t) (org-clone-local-variables source-buffer "^\\(org-\\|orgtbl-\\)") (org-install-letbind) (run-hooks (quote org-export-preprocess-hook)) (untabify (point-min) (point-max)) (org-export-handle-include-files-recurse) (run-hooks (quote org-export-preprocess-after-include-files-hook)) (org-export-remove-archived-trees archived-trees) (org-export-remove-comment-blocks-and-subtrees) (org-export-handle-export-tags (plist-get parameters :select-tags) (plist-get parameters :exclude-tags)) (run-hooks (quote org-export-preprocess-after-tree-selection-hook)) (org-export-remove-tasks (plist-get parameters :tasks)) (when (plist-get parameters :footnotes) (org-footnote-normalize nil parameters)) (org-export-mark-list-end) (org-export-preprocess-apply-macros) (run-hooks (quote org-export-preprocess-after-macros-hook)) (org-export-blocks-preprocess) (org-export-mark-list-properties) (org-export-replace-src-segments-and-examples) (org-export-protect-colon-examples) (org-export-convert-protected-spaces) (setq target-alist (org-export-define-heading-targets target-alist)) (run-hooks (quote org-export-preprocess-after-headline-targets-hook)) (org-export-remember-html-container-classes) (org-export-remove-or-extract-drawers drawers (plist-get parameters :drawers)) (when (plist-get parameters :skip-before-1st-heading) (goto-char (point-min)) (when (re-search-forward "^\\(#.*\n\\)?\\*+[ 	]" nil t) (delete-region (point-min) (match-beginning 0)) (goto-char (point-min)) (insert "\n"))) (when (plist-get parameters :add-text) (goto-char (point-min)) (insert (plist-get parameters :add-text) "\n")) (org-export-remove-headline-metadata parameters) (setq target-alist (org-export-handle-invisible-targets target-alist)) (run-hooks (quote org-export-preprocess-before-selecting-backend-code-hook)) (org-export-select-backend-specific-text) (org-export-protect-quoted-subtrees) (org-export-remove-clock-lines) (org-export-protect-verbatim) (org-export-mark-blockquote-verse-center) (run-hooks (quote org-export-preprocess-after-blockquote-hook)) (unless (plist-get parameters :timestamps) (org-export-remove-timestamps)) (setq target-alist (org-export-attach-captions-and-attributes target-alist)) (org-export-mark-radio-links) (run-hooks (quote org-export-preprocess-after-radio-targets-hook)) (org-export-concatenate-multiline-links) (run-hooks (quote org-export-preprocess-before-normalizing-links-hook)) (org-export-normalize-links) ...) rtn)
  org-export-preprocess-string(#("* Conclusion\n\n#+begin_src latex \n\n#+end_src\n" 0 2 (fontified t face org-level-1 mouse-face highlight keymap (keymap (C-down-mouse-1 . org-mouse-move-tree-start) (C-drag-mouse-1 . org-mouse-move-tree) (follow-link . mouse-face) (mouse-3) (mouse-2 . org-open-at-mouse))) 2 12 (fontified t face org-level-1) 12 13 (fontified t) 13 14 (fontified t) 14 32 (fontified t font-lock-fontified t face org-block-begin-line font-lock-multiline t) 32 33 (fontified t font-lock-fontified t font-lock-multiline t face org-block-begin-line) 33 34 (fontified t font-lock-fontified t font-lock-multiline t face org-block) 34 43 (fontified t font-lock-fontified t face org-block-end-line font-lock-multiline t) 43 44 (fontified t font-lock-fontified t face org-block-end-line)) :emph-multiline t :for-backend html :skip-before-1st-heading nil :drawers nil :todo-keywords t :tasks t :tags not-in-toc :priority nil :footnotes t :timestamps t :archived-trees headline :select-tags ("export") :exclude-tags ("noexport") :add-text nil :LaTeX-fragments t)
  (org-split-string (org-export-preprocess-string region :emph-multiline t :for-backend (quote html) :skip-before-1st-heading (plist-get opt-plist :skip-before-1st-heading) :drawers (plist-get opt-plist :drawers) :todo-keywords (plist-get opt-plist :todo-keywords) :tasks (plist-get opt-plist :tasks) :tags (plist-get opt-plist :tags) :priority (plist-get opt-plist :priority) :footnotes (plist-get opt-plist :footnotes) :timestamps (plist-get opt-plist :timestamps) :archived-trees (plist-get opt-plist :archived-trees) :select-tags (plist-get opt-plist :select-tags) :exclude-tags (plist-get opt-plist :exclude-tags) :add-text (plist-get opt-plist :text) :LaTeX-fragments (plist-get opt-plist :LaTeX-fragments)) "[\r\n]")
  (let* ((opt-plist (org-export-process-option-filters (org-combine-plists (org-default-export-plist) ext-plist (org-infile-export-plist)))) (body-only (or body-only (plist-get opt-plist :body-only))) (style (concat (if (plist-get opt-plist :style-include-default) org-export-html-style-default) (plist-get opt-plist :style) (plist-get opt-plist :style-extra) "\n" (if (plist-get opt-plist :style-include-scripts) org-export-html-scripts))) (html-extension (plist-get opt-plist :html-extension)) valid thetoc have-headings first-heading-pos (odd org-odd-levels-only) (region-p (org-region-active-p)) (rbeg (and region-p (region-beginning))) (rend (and region-p (region-end))) (subtree-p (if (plist-get opt-plist :ignore-subtree-p) nil (when region-p (save-excursion (goto-char rbeg) (and (org-at-heading-p) (>= ... rend)))))) (level-offset (if subtree-p (save-excursion (goto-char rbeg) (+ (funcall outline-level) (if org-odd-levels-only 1 0))) 0)) (opt-plist (setq org-export-opt-plist (if subtree-p (org-export-add-subtree-options opt-plist rbeg) opt-plist))) (org-current-export-dir (or pub-dir (org-export-directory :html opt-plist))) (org-current-export-file buffer-file-name) (level 0) (line "") (origline "") txt todo (umax nil) (umax-toc nil) (filename (if to-buffer nil (expand-file-name (concat (file-name-sans-extension (or ... ...)) "." html-extension) (file-name-as-directory (or pub-dir (org-export-directory :html opt-plist)))))) (current-dir (if buffer-file-name (file-name-directory buffer-file-name) default-directory)) (auto-insert nil) (buffer (if to-buffer (cond ((eq to-buffer (quote string)) (get-buffer-create "*Org HTML Export*")) (t (get-buffer-create to-buffer))) (find-file-noselect filename))) (org-levels-open (make-vector org-level-max nil)) (date (plist-get opt-plist :date)) (author (plist-get opt-plist :author)) (html-validation-link (or org-export-html-validation-link "")) (title (org-html-expand (or (and subtree-p (org-export-get-title-from-subtree)) (plist-get opt-plist :title) (and (not body-only) (not (plist-get opt-plist :skip-before-1st-heading)) (org-export-grab-title-from-buffer)) (and buffer-file-name (file-name-sans-extension (file-name-nondirectory buffer-file-name))) "UNTITLED"))) (link-up (and (plist-get opt-plist :link-up) (string-match "\\S-" (plist-get opt-plist :link-up)) (plist-get opt-plist :link-up))) (link-home (and (plist-get opt-plist :link-home) (string-match "\\S-" (plist-get opt-plist :link-home)) (plist-get opt-plist :link-home))) (dummy (setq opt-plist (plist-put opt-plist :title title))) (html-table-tag (plist-get opt-plist :html-table-tag)) (quote-re0 (concat "^ *" org-quote-string "\\( +\\|[ 	]*$\\)")) (quote-re (format org-heading-keyword-regexp-format org-quote-string)) (inquote nil) (infixed nil) (inverse nil) (email (plist-get opt-plist :email)) (language (plist-get opt-plist :language)) (keywords (plist-get opt-plist :keywords)) (description (plist-get opt-plist :description)) (num (plist-get opt-plist :section-numbers)) (lang-words nil) (head-count 0) cnt ...) (let ((inhibit-read-only t)) (org-unmodified (remove-text-properties (point-min) (point-max) (quote (:org-license-to-kill t))))) (message "Exporting...") (setq org-min-level (org-get-min-level lines level-offset)) (setq org-last-level org-min-level) (org-init-section-numbers) (cond ((and date (string-match "%" date)) (setq date (format-time-string date))) (date) (t (setq date (format-time-string "%Y-%m-%d %T %Z")))) (setq lang-words (or (assoc language org-export-language-setup) (assoc "en" org-export-language-setup))) (set-buffer buffer) (let ((inhibit-read-only t)) (erase-buffer)) (fundamental-mode) (org-install-letbind) (and (fboundp (quote set-buffer-file-coding-system)) (set-buffer-file-coding-system coding-system-for-write)) (let ((case-fold-search nil) (org-odd-levels-only odd)) (mapc (lambda (x) (set (make-local-variable (nth 2 x)) (plist-get opt-plist (car x)))) org-export-plist-vars) (setq umax (if arg (prefix-numeric-value arg) org-export-headline-levels)) (setq umax-toc (if (integerp org-export-with-toc) (min org-export-with-toc umax) umax)) (unless body-only (insert (format "%s\n<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Strict//EN\"\n               \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\">\n<html xmlns=\"http://www.w3.org/1999/xhtml\" lang=\"%s\" xml:lang=\"%s\">\n<head>\n<title>%s</title>\n<meta http-equiv=\"Content-Type\" content=\"text/html;charset=%s\"/>\n<meta name=\"title\" content=\"%s\"/>\n<meta name=\"generator\" content=\"Org-mode\"/>\n<meta name=\"generated\" content=\"%s\"/>\n<meta name=\"author\" content=\"%s\"/>\n<meta name=\"description\" content=\"%s\"/>\n<meta name=\"keywords\" content=\"%s\"/>\n%s\n%s\n</head>\n<body>\n%s\n" (format (or (and ... org-export-html-xml-declaration) (cdr ...) (cdr ...) "") (or charset "iso-8859-1")) language language title (or charset "iso-8859-1") title date author description keywords style mathjax (if (or link-up link-home) (concat (format org-export-html-home/up-format ... ...) "\n") ""))) (when (plist-get opt-plist :html-preamble) (let ((html-pre (plist-get opt-plist :html-preamble))) (insert "<div id=\"" (nth 0 org-export-html-divs) "\">\n") (cond ((stringp html-pre) (insert ...)) ((functionp html-pre) (funcall html-pre)) (t (insert ...))) (insert "\n</div>\n"))) (insert (format "\n<div id=\"%s\">" (or org-export-html-content-div (nth 1 org-export-html-divs))) "\n<h1 class=\"title\">" title "</h1>\n")) (if (and org-export-with-toc (not body-only)) (progn (push (format "<h%d>%s</h%d>\n" org-export-html-toplevel-hlevel (nth 3 lang-words) org-export-html-toplevel-hlevel) thetoc) (push "<div id=\"text-table-of-contents\">\n" thetoc) (push "<ul>\n<li>" thetoc) (setq lines (mapcar (function (lambda ... ... line)) lines)) (while (> org-last-level (1- org-min-level)) (setq org-last-level (1- org-last-level)) (push "</li>\n</ul>\n" thetoc)) (push "</div>\n" thetoc) (setq thetoc (if have-headings (nreverse thetoc) nil)))) (setq head-count 0) (org-init-section-numbers) (org-open-par) (while (setq line (pop lines) origline line) (catch (quote nextline) (when (and inquote (string-match org-outline-regexp-bol line)) (insert "</pre>\n") (org-open-par) (setq inquote nil)) (when inquote (insert (org-html-protect line) "\n") (throw (quote nextline) nil)) (when (and org-export-with-fixed-width (string-match "^[ 	]*:\\(\\([ 	]\\|$\\)\\(.*\\)\\)" line)) (when (not infixed) (setq infixed t) (org-close-par-maybe) (insert "<pre class=\"example\">\n")) (insert (org-html-protect (match-string 3 line)) "\n") (when (or (not lines) (not ...)) (setq infixed nil) (insert "</pre>\n") (org-open-par)) (throw (quote nextline) nil)) (when (and (get-text-property 0 (quote org-protected) line) (not (< ... ...))) (let (par (ind ...)) (when (re-search-backward "\\(<p>\\)\\([ 	\r\n]*\\)\\=" ... t) (setq par ...) (replace-match "\\2\n")) (insert line "\n") (while (and lines ... ...) (insert ... "\n")) (and par (insert "<p>\n"))) (throw (quote nextline) nil)) (when (equal "ORG-BLOCKQUOTE-START" line) (org-close-par-maybe) (insert "<blockquote>\n") (org-open-par) (throw (quote nextline) nil)) (when (equal "ORG-BLOCKQUOTE-END" line) (org-close-par-maybe) (insert "\n</blockquote>\n") (org-open-par) (throw (quote nextline) nil)) (when (equal "ORG-VERSE-START" line) (org-close-par-maybe) (insert "\n<p class=\"verse\">\n") (setq org-par-open t) (setq inverse t) (throw (quote nextline) nil)) (when (equal "ORG-VERSE-END" line) (insert "</p>\n") (setq org-par-open nil) (org-open-par) (setq inverse nil) (throw (quote nextline) nil)) (when (equal "ORG-CENTER-START" line) (org-close-par-maybe) (insert "\n<div style=\"text-align: center\">") (org-open-par) (throw (quote nextline) nil)) (when (equal "ORG-CENTER-END" line) (org-close-par-maybe) (insert "\n</div>") (org-open-par) (throw (quote nextline) nil)) (run-hooks (quote org-export-html-after-blockquotes-hook)) (when inverse (let ((i ...)) (if (> i 0) (setq line ...)) (unless (string-match "\\\\\\\\[ 	]*$" line) (setq line ...)))) (setq start 0) (while (string-match "<<<?\\([^<>]*\\)>>>?\\((INVISIBLE)\\)?[ 	]*\n?" line start) (cond ((get-text-property ... ... line) (setq start ...)) ((match-end 2) (setq line ...)) ((and org-export-with-toc ...) (setq line ...)) (t (setq line ...)))) (setq line (org-html-handle-time-stamps line)) (or (string-match org-table-hline-regexp line) (string-match "^[ 	]*\\([+]-\\||[ ]\\)[-+ |]*[+|][ 	]*$" line) (setq line (org-html-expand line))) (setq line (org-html-handle-links line opt-plist)) (if (and org-todo-line-regexp (string-match org-todo-line-regexp line) (match-beginning 2)) (setq line (concat (substring line 0 ...) "<span class=\"" (if ... "done" "todo") " " (match-string 2 line) "\"> " (org-export-html-get-todo-kwd-class-name ...) "</span>" (substring line ...)))) (when org-export-with-footnotes (setq start 0) (while (string-match "\\([^* 	].*?\\)\\[\\([0-9]+\\)\\]" line start) (if (or ... ...) (setq start ...) (let ... ... ...)))) (cond ((string-match "^\\(\\*+\\)\\(?: +\\(.*?\\)\\)?[ 	]*$" line) (setq level (org-tr-level ...) txt (match-string 2 line)) (if (string-match quote-re0 txt) (setq txt ...)) (if (<= level ...) (setq head-count ...)) (setq first-heading-pos (or first-heading-pos ...)) (org-html-level-start level txt umax (and org-export-with-toc ...) head-count opt-plist) (when (string-match quote-re line) (org-close-par-maybe) (insert "<pre>") (setq inquote t))) ((and org-export-with-tables (string-match "^\\([ 	]*\\)\\(|\\|\\+-+\\+\\)" line)) (when (not table-open) (setq table-open t table-buffer nil table-orig-buffer nil)) (setq table-buffer (cons line table-buffer) table-orig-buffer (cons origline table-orig-buffer)) (when (or ... ...) (setq table-open nil table-buffer ... table-orig-buffer ...) (org-close-par-maybe) (insert ...))) (t (when (get-text-property 0 ... line) (setq line ...)) (when (string-match "^[ 	]*-\\{5,\\}[ 	]*$" line) (if org-par-open ... ...) (throw ... nil)) (if (string-match "^ [-+*]-\\|^[ 	]*$" line) (org-open-par)) (when org-export-with-footnotes (when ... ...) (when ... ... ...)) (cond (... ...) (org-export-preserve-breaks ...)) (let (...) (while ... ... ...)) (insert line "\n"))))) (when inquote (insert "</pre>\n") (org-open-par)) (org-html-level-start 1 nil umax (and org-export-with-toc (<= level umax)) head-count opt-plist) (when (and (> umax 0) first-heading-pos) (insert "</div>\n")) (save-excursion (goto-char (point-min)) (while (re-search-forward "\\(\\(<p class=\"footnote\">\\)[^\0]*?\\)\\(\\(\\2\\)\\|\\'\\)" nil t) (push (match-string 1) footnotes) (replace-match "\\4" t nil) (goto-char (match-beginning 0)))) (when footnotes (insert (format org-export-html-footnotes-section (nth 4 lang-words) (mapconcat (quote identity) (nreverse footnotes) "\n")) "\n")) (let ((bib (org-export-html-get-bibliography))) (when bib (insert "\n" bib "\n"))) (unless body-only (insert "</div>\n") (let ((html-post (plist-get opt-plist :html-postamble)) (email (mapconcat (lambda ... ...) (split-string email ",+ *") ", ")) (creator-info (concat "Org version " org-version " with Emacs version " (number-to-string emacs-major-version)))) (when (plist-get opt-plist :html-postamble) (insert "\n<div id=\"" (nth 2 org-export-html-divs) "\">\n") (cond ((stringp html-post) (insert ...)) ((functionp html-post) (funcall html-post)) ((eq html-post ...) (when ... ...) (when ... ...) (when ... ...) (when ... ...) (insert html-validation-link "\n")) (t (insert ...))) (insert "\n</div>")))) (if org-export-html-with-timestamp (insert org-export-html-html-helper-timestamp)) (unless body-only (insert "\n</body>\n</html>\n")) (unless (plist-get opt-plist :buffer-will-be-killed) (normal-mode) (if (eq major-mode (default-value (quote major-mode))) (html-mode))) (goto-char (point-min)) (when thetoc (if (or (re-search-forward "<p>\\s-*\\[TABLE-OF-CONTENTS\\]\\s-*</p>" nil t) (re-search-forward "\\[TABLE-OF-CONTENTS\\]" nil t)) (progn (goto-char (match-beginning 0)) (replace-match "")) (goto-char first-heading-pos) (when (looking-at "\\s-*</p>") (goto-char (match-end 0)) (insert "\n"))) (insert "<div id=\"table-of-contents\">\n") (let ((beg (point))) (mapc (quote insert) thetoc) (insert "</div>\n") (while (re-search-backward "<li>[ \r\n	]*</li>\n?" beg t) (replace-match "")))) (goto-char (point-min)) (while (re-search-forward "<p>[ \r\n	]*</p>" nil t) (replace-match "")) (goto-char (point-min)) (goto-char (point-min)) (let (beg end n) (while (setq beg (next-single-property-change (point) (quote org-whitespace))) (setq n (get-text-property beg (quote org-whitespace)) end (next-single-property-change beg (quote org-whitespace))) (goto-char beg) (delete-region beg end) (insert (format "<span style=\"visibility:hidden;\">%s</span>" (make-string n 120))))) (goto-char (point-min)) (when (looking-at "\\s-+\n") (replace-match "")) (remove-text-properties (point-min) (point-max) (quote (display t))) (run-hooks (quote org-export-html-final-hook)) (or to-buffer (save-buffer)) (goto-char (point-min)) (or (org-export-push-to-kill-ring "HTML") (message "Exporting... done")) (if (eq to-buffer (quote string)) (prog1 (buffer-substring (point-min) (point-max)) (kill-buffer (current-buffer))) (current-buffer))))
  org-export-as-html(nil)
  call-interactively(org-export-as-html)
  (if (and bg (nth 2 ass) (not (buffer-base-buffer)) (not (org-region-active-p))) (let ((p (start-process (concat "Exporting " (file-name-nondirectory (buffer-file-name))) "*Org Processes*" (expand-file-name invocation-name invocation-directory) "-batch" "-l" user-init-file "--eval" "(require 'org-exp)" "--eval" "(setq org-wait .2)" (buffer-file-name) "-f" (symbol-name (nth 1 ass))))) (set-process-sentinel p (quote org-export-process-sentinel)) (message "Background process \"%s\": started" p)) (if subtree-p (progn (org-mark-subtree) (org-activate-mark))) (call-interactively (nth 1 ass)) (when (and bpos (get-buffer-window cbuf)) (let ((cw (selected-window))) (select-window (get-buffer-window cbuf)) (goto-char cpos) (deactivate-mark) (select-window cw))))
  (let* ((bg (org-xor (equal arg (quote (16))) org-export-run-in-background)) (subtree-p (or (org-region-active-p) (eq org-export-initial-scope (quote subtree)))) (help "[t]   insert the export option template\n[v]   limit export to visible part of outline tree\n[1]   switch buffer/subtree export\n[SPC] publish enclosing subtree (with LaTeX_CLASS or EXPORT_FILE_NAME prop)\n\n[a/n/u] export as ASCII/Latin-1/UTF-8         [A/N/U] to temporary buffer\n\n[h] export as HTML      [H] to temporary buffer   [R] export region\n[b] export as HTML and open in browser\n\n[l] export as LaTeX     [L] to temporary buffer\n[p] export as LaTeX and process to PDF            [d] ... and open PDF file\n\n[D] export as DocBook   [V] export as DocBook, process to PDF, and open\n\n[o] export as OpenDocumentText                    [O] ... and open\n\n[j] export as TaskJuggler                         [J] ... and open\n\n[m] export as Freemind mind map\n[x] export as XOXO\n[g] export using Wes Hardaker's generic exporter\n\n[i] export current file as iCalendar file\n[I] export all agenda files as iCalendar files   [c] ...as one combined file\n\n[F] publish current file          [P] publish current project\n[X] publish a project...          [E] publish every projects") (cmds (quote ((116 org-insert-export-options-template nil) (118 org-export-visible nil) (97 org-export-as-ascii t) (65 org-export-as-ascii-to-buffer t) (110 org-export-as-latin1 t) (78 org-export-as-latin1-to-buffer t) (117 org-export-as-utf8 t) (85 org-export-as-utf8-to-buffer t) (104 org-export-as-html t) (98 org-export-as-html-and-open t) (72 org-export-as-html-to-buffer nil) (82 org-export-region-as-html nil) (120 org-export-as-xoxo t) (103 org-export-generic t) (68 org-export-as-docbook t) (86 org-export-as-docbook-pdf-and-open t) (111 org-export-as-odt t) (79 org-export-as-odt-and-open t) (106 org-export-as-taskjuggler t) (74 org-export-as-taskjuggler-and-open t) (109 org-export-as-freemind t) (108 org-export-as-latex t) (112 org-export-as-pdf t) (100 org-export-as-pdf-and-open t) (76 org-export-as-latex-to-buffer nil) (105 org-export-icalendar-this-file t) (73 org-export-icalendar-all-agenda-files t) (99 org-export-icalendar-combine-agenda-files t) (70 org-publish-current-file t) (80 org-publish-current-project t) (88 org-publish t) (69 org-publish-all t)))) r1 r2 ass (cpos (point)) (cbuf (current-buffer)) bpos) (save-excursion (save-window-excursion (if subtree-p (message "Export subtree: ") (message "Export buffer: ")) (delete-other-windows) (with-output-to-temp-buffer "*Org Export/Publishing Help*" (princ help)) (org-fit-window-to-buffer (get-buffer-window "*Org Export/Publishing Help*")) (while (eq (setq r1 (read-char-exclusive)) 49) (cond (subtree-p (setq subtree-p nil) (message "Export buffer: ")) ((not subtree-p) (setq subtree-p t) (setq bpos (point)) (message "Export subtree: ")))) (when (eq r1 32) (let ((case-fold-search t) (end (save-excursion ... ...))) (outline-next-heading) (if (re-search-backward "^[ 	]+\\(:latex_class:\\|:export_title:\\|:export_file_name:\\)[ 	]+\\S-" end t) (progn (org-back-to-heading t) (setq subtree-p t) (setq bpos ...) (message "Select command (for subtree): ") (setq r1 ...)) (error "No enclosing node with LaTeX_CLASS or EXPORT_TITLE or EXPORT_FILE_NAME")))))) (if (fboundp (quote redisplay)) (redisplay)) (and bpos (goto-char bpos)) (setq r2 (if (< r1 27) (+ r1 96) r1)) (unless (setq ass (assq r2 cmds)) (error "No command associated with key %c" r1)) (if (and bg (nth 2 ass) (not (buffer-base-buffer)) (not (org-region-active-p))) (let ((p (start-process (concat "Exporting " (file-name-nondirectory ...)) "*Org Processes*" (expand-file-name invocation-name invocation-directory) "-batch" "-l" user-init-file "--eval" "(require 'org-exp)" "--eval" "(setq org-wait .2)" (buffer-file-name) "-f" (symbol-name (nth 1 ass))))) (set-process-sentinel p (quote org-export-process-sentinel)) (message "Background process \"%s\": started" p)) (if subtree-p (progn (org-mark-subtree) (org-activate-mark))) (call-interactively (nth 1 ass)) (when (and bpos (get-buffer-window cbuf)) (let ((cw (selected-window))) (select-window (get-buffer-window cbuf)) (goto-char cpos) (deactivate-mark) (select-window cw)))))
  org-export(nil)
  call-interactively(org-export nil nil)

Re: [RFC] Standardized code block keywords

[Thomas S. Dye]

And, revising the files before Worg updates the Org-mode it uses will
break them, right?

Tom

Nick Dokos <nicholas.dokos@hp.com> writes:

> I'm trying to add a note to Worg hacks but before I push, I use my local
> org setup to publish Worg locally and take a look at it (not entirely reliable
> since my org version is usually different from the real Worg one, but a
> good indication of problems before they happen nevertheless). I ran into
> a couple of problems. 
>
> The first one is expected: I'm running with Eric's patch, so when
> processing Worg/org-contrib/babel/examples/o18.org (Tom Dye's article on
> Archaelogy in Oceania), I ran into #+srcname vs #+name problems: when
> Eric's changes do go into org and the new org is used to publish Worg,
> there is going to be some breakage. Actually, o18.org is the extent of
> breakage that I saw, so it doesn't look too bad.
>
> But I also ran into a second (unrelated) issue. Here's a minimal example:
>
> * Conclusion
>
> #+begin_src latex 
>
> #+end_src
>
> Exporting to html gives me the attached backtrace. But the underlying reason
> is easy to demonstrate: if you C-c C-c on the empty source block, you get:
>
> ,----
> | * Conclusion
> | 
> | #+begin_src latex 
> | 
> | #+end_src
> | 
> | #+results:
> | #+END_LaTeX
> | #+BEGIN_LaTeX
> `----
>
> Nick
>
> Versions:
> Org-mode version 7.7 (release_7.7.485.gcfed6.dirty)
> GNU Emacs 24.0.90.2 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.0) of 2011-10-27
>
>
>

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [RFC] Standardized code block keywords

[Nick Dokos]

Thomas S. Dye <tsd@tsdye.com> wrote:

> And, revising the files before Worg updates the Org-mode it uses will
> break them, right?

Yup - they got to be done at the same time.

Nick

> 
> Tom
> 
> Nick Dokos <nicholas.dokos@hp.com> writes:
> 
> > I'm trying to add a note to Worg hacks but before I push, I use my local
> > org setup to publish Worg locally and take a look at it (not entirely reliable
> > since my org version is usually different from the real Worg one, but a
> > good indication of problems before they happen nevertheless). I ran into
> > a couple of problems. 
> >
> > The first one is expected: I'm running with Eric's patch, so when
> > processing Worg/org-contrib/babel/examples/o18.org (Tom Dye's article on
> > Archaelogy in Oceania), I ran into #+srcname vs #+name problems: when
> > Eric's changes do go into org and the new org is used to publish Worg,
> > there is going to be some breakage. Actually, o18.org is the extent of
> > breakage that I saw, so it doesn't look too bad.
> >
> > But I also ran into a second (unrelated) issue. Here's a minimal example:
> >
> > * Conclusion
> >
> > #+begin_src latex 
> >
> > #+end_src
> >
> > Exporting to html gives me the attached backtrace. But the underlying reason
> > is easy to demonstrate: if you C-c C-c on the empty source block, you get:
> >
> > ,----
> > | * Conclusion
> > | 
> > | #+begin_src latex 
> > | 
> > | #+end_src
> > | 
> > | #+results:
> > | #+END_LaTeX
> > | #+BEGIN_LaTeX
> > `----
> >
> > Nick
> >
> > Versions:
> > Org-mode version 7.7 (release_7.7.485.gcfed6.dirty)
> > GNU Emacs 24.0.90.2 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.0) of 2011-10-27
> >
> >
> >
> 
> -- 
> Thomas S. Dye
> http://www.tsdye.com
> 

Re: [RFC] Standardized code block keywords

[Daniel Bausch]

I did some tests with my documents and they look fine.  Thanks for your work.

(A minor remark, offtopic: If the document ends just below a source code 
block, no results are inserted when the block is executed.  You have to insert 
an additional blank line, for a result to can appear.)

Daniel

Am Freitag 28 Oktober 2011, 20:52:48 schrieb Eric Schulte:
> Nick Dokos <nicholas.dokos@hp.com> writes:
> > Eric Schulte <schulte.eric@gmail.com> wrote:
> >> The attached updated patch fixes a bug in the original.
> > 
> > Minor problem in applying:
> > 
> > ,----
> > 
> > | $ git apply ~/Mail/inbox/724
> > | /home/nick/Mail/inbox/724:671: trailing whitespace.
> > | #+name:
> > | /home/nick/Mail/inbox/724:599: new blank line at EOF.
> > | +
> > | warning: 2 lines add whitespace errors.
> > 
> > `----
> 
> The attached version fixes these issues, Thanks -- Eric

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Eric Schulte]

It is now possible to specify multi-line properties using a property
block.  This should make it more natural to specify many file-wide
variables through properties.  For example,

  #+begin_property
    var foo=1,
        bar=2,
        baz=3,
        qux=4
  #+end_property

  #+begin_src emacs-lisp
    (+ foo bar baz qux)
  #+end_src

  #+results:
  : 10

Cheers -- Eric

Darlan Cavalcante Moreira <darcamo@gmail.com> writes:

> I didn't check the list for 3 days and this thread became a little hard to
> follow. So, forgive me if I'm "answering" the wrong E-Mail.
>
>
> I liked Christian's idea of using a single "var" property to tell babel
> which regular properties it should use as variables (ignoring any variable
> not defined). This would be enough for my use cases.
>
> On the other hand, some way to append values to a property, such as using
> some special keyword as I have suggested, could be a better solution in
> order to keep consistence if people want this feature for non-babel related
> properties.
>
> --
> Darlan
>
> At Sat, 22 Oct 2011 09:53:25 -0600,
> Eric Schulte wrote:
>> 
>> Darlan Cavalcante Moreira <darcamo@gmail.com> writes:
>> 
>> > It's excellent that now babel understands multiple values in the "var"
>> > property (I was one of the people that wanted this), but "There Is One More
>> > Thing".
>> >
>> > Would it be feasible to inherit variables from parent sub-trees?
>> > Effectively, I'd like to append new values in lower level sub-trees, but
>> > AFAIK setting the var property in a sub-tree will still replace the value
>> > set in the parent sub-tree.
>> >
>> 
>> Currently every new property specification entirely replaced previous
>> specifications with the same name.
>> 
>> >
>> > That is, in the example below the level-2 sub-trees would not have the foo
>> > variable passed to babel.
>> > * Code with foo
>> >   :PROPERTIES:
>> >   :var:      foo=1
>> >   :END:
>> >
>> > ** Code only with bar
>> >    :PROPERTIES:
>> >    :var:      bar=2
>> >    :END:
>> >    src_block
>> > ** Code only with baz
>> >    :PROPERTIES:
>> >    :var:      baz=3
>> >    :END:
>> >    src_block
>> >
>> > Maybe a special keyword, such as "inherit" (or "append") could be used to
>> > incorporate variables defined in the parent sub-tree, such that the example
>> > would become
>> > * Code with foo
>> >   :PROPERTIES:
>> >   :var:      foo=1
>> >   :END:
>> >
>> > ** Code with foo and bar
>> >    :PROPERTIES:
>> >    :var:      bar=2, inherit
>> >    :END:
>> >    src_block
>> > ** Code with foo and baz
>> >    :PROPERTIES:
>> >    :var:      baz=3, inherit
>> >    :END:
>> >    src_block
>> >
>> > This should not affect global variables and "inherit" would inherit
>> > variables defined only in the parent sub-tree (unless it also contains the
>> > inherit keyword).
>> >
>> > As a use case scenario, suppose I need to perform simulations for a few
>> > different scenarios, each with small variations. This would allow me to
>> > define common variables for a scenario in a higher level sub-tree and more
>> > specific variables in the lower level sub-trees.
>> >
>> 
>> This sounds somewhat similar to my suggestion in reply to Rainer's
>> email.
>> 
>> Best -- Eric
>> 
>> >
>> > --
>> > Darlan Cavalcante
>> >
>> >
>> > At Fri, 21 Oct 2011 22:24:25 +0200,
>> > Christian Moe <mail@christianmoe.com> wrote:
>> >> 
>> >> Hi,
>> >> 
>> >> Yes, that works nicely, and should solve Rainer's problem.
>> >> I haven't been able to think of anything else that can't be handled by 
>> >> properties.
>> >> 
>> >> And I do think it's a good idea to winnow down the syntax a bit, even 
>> >> if things break. I just like to grumble.
>> >> :-)
>> >> 
>> >> Yours,
>> >> Christian
>> >> 
>> >> On 10/21/11 7:37 PM, Eric Schulte wrote:
>> >> > Nice idea.  This same issue with "var" arose when we first started
>> >> > allowing header arguments to be specified inside subtree properties.
>> >> > I've just implemented your suggestion so the following are now possible.
>> >> >
>> >> > #+PROPERTY: var foo=1, bar=2
>> >> > #+PROPERTY: cache yes
>> >> >
>> >> > #+begin_src emacs-lisp
>> >> >    (+ foo bar)
>> >> > #+end_src
>> >> >
>> >> > #+results[be32e67491d4e92f75769aebe423c20ca01626fe]:
>> >> > : 3
>> >> >
>> >> > and
>> >> >
>> >> > #+begin_src emacs-lisp :var foo="this", bar="that"
>> >> >    (concat foo " " bar)
>> >> > #+end_src
>> >> >
>> >> > #+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]:
>> >> > : this that
>> >> >
>> >> > Thanks for the suggestion and I hope the above is a sufficient
>> >> > replacement for the now-missing #+BABEL: syntax.
>> >> >
>> >> > Cheers -- Eric
>> >> 
>> >> 
>> 
>> -- 
>> Eric Schulte
>> http://cs.unm.edu/~eschulte/

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [RFC] Standardized code block keywords

[Eric Schulte]

Daniel Bausch <DanielBausch@gmx.de> writes:

> I did some tests with my documents and they look fine.  Thanks for your work.
>

Great, good to know.

>
> (A minor remark, offtopic: If the document ends just below a source
> code block, no results are inserted when the block is executed.  You
> have to insert an additional blank line, for a result to can appear.)
>

I can't reproduce this problem.

Best -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Samuel Wales]

On 2011-10-31, Eric Schulte <schulte.eric@gmail.com> wrote:
> It is now possible to specify multi-line properties using a property
> block.  This should make it more natural to specify many file-wide
> variables through properties.  For example,

Could this be changed to work using the property drawer?

[ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Samuel Wales]

Hi Eric,

Properties can be specified in the properties drawer.  But
multiple-line ones cannot at present (at least not without serializing the way
multiple-line macros are serialized).

Therefore you propose new syntax for multiple-line properties.

I propose that allowing the properties drawer to handle multiple-line
properties might have 3 advantages over adding block syntax.

1: If you want a single-line property, you have a choice.  If you want
a multiple-line
property, you have to use a block.  That seems inconsistent.

2: Some people would probably have use for multiple-line properties, such
as in org-contacts.  Doesn't have to be Babel.  People are used to the
properties drawer.  Also, external parsers are.

3: Nic objects to blocks without discussing them first.

Perhaps upgrading properties drawer will satisfy that objection /and/ be
consistent /and/ allow further uses in Org.

This all presumes we're sticking with properties for Babel.

Samuel

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com
===
Bigotry against people with serious diseases is still bigotry.



-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com
===
Bigotry against people with serious diseases is still bigotry.

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Eric Schulte]

My concerns with respect to a property drawer solution are two fold.

1) In the same way that #+PROPERTY: assumes its value will live on a
   single line, property drawers assume that their values will live on a
   single line.  I don't see how it will be easier to fold multi-line
   properties into drawers than outside of drawers.

2) It is not possible to specify file-wide properties with drawers,
   unlike with property lines.

Thanks -- Eric

Samuel Wales <samologist@gmail.com> writes:

> Hi Eric,
>
> Properties can be specified in the properties drawer.  But
> multiple-line ones cannot at present (at least not without serializing the way
> multiple-line macros are serialized).
>
> Therefore you propose new syntax for multiple-line properties.
>
> I propose that allowing the properties drawer to handle multiple-line
> properties might have 3 advantages over adding block syntax.
>
> 1: If you want a single-line property, you have a choice.  If you want
> a multiple-line
> property, you have to use a block.  That seems inconsistent.
>
> 2: Some people would probably have use for multiple-line properties, such
> as in org-contacts.  Doesn't have to be Babel.  People are used to the
> properties drawer.  Also, external parsers are.
>
> 3: Nic objects to blocks without discussing them first.
>
> Perhaps upgrading properties drawer will satisfy that objection /and/ be
> consistent /and/ allow further uses in Org.
>
> This all presumes we're sticking with properties for Babel.
>
> Samuel
>
> -- 
> The Kafka Pandemic: http://thekafkapandemic.blogspot.com
> ===
> Bigotry against people with serious diseases is still bigotry.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: C-c C-c not working at end of #+end_src line (was: [RFC] Standardized code block keywords)

[Daniel Bausch]

Am Montag 31 Oktober 2011, 20:01:14 schrieb Eric Schulte:
> Daniel Bausch <DanielBausch@gmx.de> writes:
> > I did some tests with my documents and they look fine.  Thanks for your
> > work.
> 
> Great, good to know.
> 
> > (A minor remark, offtopic: If the document ends just below a source
> > code block, no results are inserted when the block is executed.  You
> > have to insert an additional blank line, for a result to can appear.)
> 
> I can't reproduce this problem.

Ok, I played around and found that what I saw has nothing to do with a blank 
line existing or not, but only with the position of point.  What I observed 
happens if point is at the end of the #+end_src line.  If you press C-c C-c 
there then you get "Local setup has been refreshed" if there is a newline 
following.  If the documents ends just there, then you get "org-mode 
fontification error".  In both cases no result is produced.  I think it is a 
very common case that one wants to execute a code block right after typing 
#+end_src, so that point position should "belong" to the code block.  If you 
move one character left, so you are between r and c, then C-c C-c works as 
expected.

If you need an example, use that

#+begin_src R
  42
#+end_src

It even does not matter, whether there is additional text following.

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Nick Dokos]

Eric Schulte <schulte.eric@gmail.com> wrote:

> My concerns with respect to a property drawer solution are two fold.
> 
> 1) In the same way that #+PROPERTY: assumes its value will live on a
>    single line, property drawers assume that their values will live on a
>    single line.  I don't see how it will be easier to fold multi-line
>    properties into drawers than outside of drawers.
> 
> 2) It is not possible to specify file-wide properties with drawers,
>    unlike with property lines.
> 
> Thanks -- Eric
> 

I felt uneasy about #+begin_property, but I could not articulate
my unease until first Nicolas and then Samuel expressed some of their
concerns.

But it seemed to me from the beginning that properties were *not* the
right fit for babel whole-file args and I'm more convinced than ever
that this is the *wrong* direction: it conflates different concepts
and it forces changes in a well established area in order to satisfy
the concerns of the other area.

Can we please back off this path? The changes are big, they affect
users' everyday work and it is not clear where they are going to end up.
Let's revert the changes to master, establish a branch, and do all this
experimentation in a branch. When it is thoroughly cooked to most
people's satisfaction, it can be merged into master. That way, people
can continue their daily work, without having to worry about changing
their files to satisfy the new changes.

Git provided exceptionally flexible branching: let's use it.

My two cents,
Nick

> Samuel Wales <samologist@gmail.com> writes:
> 
> > Hi Eric,
> >
> > Properties can be specified in the properties drawer.  But
> > multiple-line ones cannot at present (at least not without serializing the way
> > multiple-line macros are serialized).
> >
> > Therefore you propose new syntax for multiple-line properties.
> >
> > I propose that allowing the properties drawer to handle multiple-line
> > properties might have 3 advantages over adding block syntax.
> >
> > 1: If you want a single-line property, you have a choice.  If you want
> > a multiple-line
> > property, you have to use a block.  That seems inconsistent.
> >
> > 2: Some people would probably have use for multiple-line properties, such
> > as in org-contacts.  Doesn't have to be Babel.  People are used to the
> > properties drawer.  Also, external parsers are.
> >
> > 3: Nic objects to blocks without discussing them first.
> >
> > Perhaps upgrading properties drawer will satisfy that objection /and/ be
> > consistent /and/ allow further uses in Org.
> >
> > This all presumes we're sticking with properties for Babel.
> >
> > Samuel
> >
> > -- 
> > The Kafka Pandemic: http://thekafkapandemic.blogspot.com
> > ===
> > Bigotry against people with serious diseases is still bigotry.
> 
> -- 
> Eric Schulte
> http://cs.unm.edu/~eschulte/
> 

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Nick Dokos]

Nick Dokos <nicholas.dokos@hp.com> wrote:


> Can we please back off this path? 

In order to prevent confusion or needless argument: the path I think we
should back off of is the committing of these changes to master - I think
the work should be done in a branch and cooked thoroughly before merging
it to master.

I did not mean to imply (although I think one could easily get that impression
from my mail) backing off the property implementation (despite my personal
reservations about that).

Nick

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Eric Schulte]

Nick Dokos <nicholas.dokos@hp.com> writes:

> Nick Dokos <nicholas.dokos@hp.com> wrote:
>
>
>> Can we please back off this path? 
>
> In order to prevent confusion or needless argument: the path I think we
> should back off of is the committing of these changes to master - I think
> the work should be done in a branch and cooked thoroughly before merging
> it to master.
>

I would agree that these changes should be happening in branches if the
problems were technical, however the issues that need to be addressed
are social issues of consensus, and for better or worse pushing changes
to the master branch is the best way to alert all interested actors and
begin the consensus-building process.

If these changes had been pushed up to a branch they would be sitting
happily in that branch with no-one noticing or objecting.  They had been
discussed at length on list before their implementation and commitance,
but this most recent round of discussion was caused by a push to the
master branch.

This is also after all the development repository, and while I do try
very hard never to break this head of this repository at the same time I
think it is an acceptable place to try out new functionality.

>
> I did not mean to imply (although I think one could easily get that impression
> from my mail) backing off the property implementation (despite my personal
> reservations about that).
>

OK, good, because I *do* think that properties are a natural fit for
specifying code block parameters.  The use of subtree properties has
already proven itself, and file-wide properties are a natural extension
(much more natural than the introduction of a #+BABEL: header argument).

While there is certainly some pain in this process I think it is nailing
down both the needs for code block properties as well as the scope of
what is and is not desirable functionality for properties in general.

Best -- Eric

>
> Nick
>
>
>
>
>
>
>
>
>
>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 4302 bytes --]

On Tue, Nov 1, 2011 at 4:17 PM, Eric Schulte <schulte.eric@gmail.com> wrote:

> Nick Dokos <nicholas.dokos@hp.com> writes:
>
> > Nick Dokos <nicholas.dokos@hp.com> wrote:
> >
> >
> >> Can we please back off this path?
> >
> > In order to prevent confusion or needless argument: the path I think we
> > should back off of is the committing of these changes to master - I think
> > the work should be done in a branch and cooked thoroughly before merging
> > it to master.
> >
>

Partly agree here - I was bitten by the changes, and have suspended work on
one project until this issue stabilizes - I do not want to change my files
after each change.


>
> I would agree that these changes should be happening in branches if the
> problems were technical, however the issues that need to be addressed
> are social issues of consensus, and for better or worse pushing changes
> to the master branch is the best way to alert all interested actors and
> begin the consensus-building process.
>
> If these changes had been pushed up to a branch they would be sitting
> happily in that branch with no-one noticing or objecting.  They had been
> discussed at length on list before their implementation and commitance,
> but this most recent round of discussion was caused by a push to the
> master branch.
>
>
You are definitely right about that - but it is kind of forcing the issue
on to users after telling them they should use git as org is very dynamic,
which is a risky business, as it might put users of - consider a new org
user who realizes that regularly things are changing which affect him, and
he / she has to change aspects of their org files. I would say it is a
double edged sword.

This is also after all the development repository, and while I do try
> very hard never to break this head of this repository at the same time I
> think it is an acceptable place to try out new functionality.
>

Again - true, but it is always recommended on the org-list to use the git
repo, as it contains all bug fixes.


> >
> > I did not mean to imply (although I think one could easily get that
> impression
> > from my mail) backing off the property implementation (despite my
> personal
> > reservations about that).
> >
>
> OK, good, because I *do* think that properties are a natural fit for
> specifying code block parameters.  The use of subtree properties has
> already proven itself, and file-wide properties are a natural extension
> (much more natural than the introduction of a #+BABEL: header argument).
>

Then one should possibly also think of merging #+LATEX into #+PROPERTY -
which I think would make it more consistent (and this is a serious
suggestion).
So: all file-wide properties, #+PROPERTIES is used.

What would be really important, is to have one page on worg, on which this
process is documented - i.e. how files need to be changed, to be used with
which version of org. I definitely have no idea, how I have to modify my
files at the moment (there was the discussion abour source_name, name, ...
and then the #+PROPERTY - I hope I haven't missed anything?). As I said - I
have the luck, that I can wait until it stabilizes (at least I hope) - but
a regularly updated summary with changes would be very welcome (and I guess
I can speak for many org users).

Even if this step is painful for many (especially the ones not to familiar
with the inner workings of org and babel (this definitely includes me)), I
am sure that the best solution will be found (hopefully soon) and we will
have a better and stronger org-mode at hand.

Cheers,

Rainer


> While there is certainly some pain in this process I think it is nailing
> down both the needs for code block properties as well as the scope of
> what is and is not desirable functionality for properties in general.
>
> Best -- Eric
>
> >
> > Nick
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
> --
> Eric Schulte
> http://cs.unm.edu/~eschulte/
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax (F):       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

[-- Attachment #2: Type: text/html, Size: 5902 bytes --]

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Nicolas Goaziou]

Hello,

Rainer M Krug <r.m.krug@gmail.com> writes:

> Then one should possibly also think of merging #+LATEX into #+PROPERTY -
> which I think would make it more consistent (and this is a serious
> suggestion).

Are you sure you're talking about the "#+LATEX:" keywords, allowing to
insert LaTeX code only for the LaTeX exporter? If that's the case,
I fail to see your point.

> So: all file-wide properties, #+PROPERTIES is used.

"#+PROPERTIES:" isn't really about file-wide properties, but only about
properties applying to each headline in the buffer. It's
a generalization of the property drawers. That's quite different,
actually. For example, "#+TITLE:" is a file-wide property that doesn't
belong to "#+PROPERTIES:".

In other words, a property should belong to "#+PROPERTIES" if it may
have different values for different sections.


Regards,

-- 
Nicolas Goaziou

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Brian Wightman]

On Tue, Nov 1, 2011 at 10:17 AM, Eric Schulte <schulte.eric@gmail.com> wrote:
> This is also after all the development repository, and while I do try
> very hard never to break this head of this repository at the same time I
> think it is an acceptable place to try out new functionality.

Given that a common recommendation for a bug fix is to 'try commit
blah blah blah', would it make sense to have bug fixes go onto a
'maint' branch (as well as master), and new features / changed
features stay on the master branch?  At the time when 'master' is
ready for a new official release, it could then be merged into 'maint'
to create the next stable point for bug fixes.

Adding features on the same branch as bug fixes, when 'official
releases' are not made frequently seems to be a formula for
frustration.

Thoughts?

Brian

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]

On Wed, Nov 2, 2011 at 1:18 PM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:

> Hello,
>
> Rainer M Krug <r.m.krug@gmail.com> writes:
>
> > Then one should possibly also think of merging #+LATEX into #+PROPERTY -
> > which I think would make it more consistent (and this is a serious
> > suggestion).
>
> Are you sure you're talking about the "#+LATEX:" keywords, allowing to
> insert LaTeX code only for the LaTeX exporter? If that's the case,
> I fail to see your point.
>
> > So: all file-wide properties, #+PROPERTIES is used.
>
> "#+PROPERTIES:" isn't really about file-wide properties, but only about
> properties applying to each headline in the buffer. It's
> a generalization of the property drawers. That's quite different,
> actually. For example, "#+TITLE:" is a file-wide property that doesn't
> belong to "#+PROPERTIES:".
>
> In other words, a property should belong to "#+PROPERTIES" if it may
> have different values for different sections.
>
>
>
I am now completely confused - but that is fine. I give up for now. Just
one question: could you, Eric, please give a summary, as soon as the
changes are fixed, on how I have to change my org-files so that they are
working again?

Thanks,

Rainer





> Regards,
>
> --
> Nicolas Goaziou
>



-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax (F):       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

[-- Attachment #2: Type: text/html, Size: 2478 bytes --]

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 1512 bytes --]

On Wed, Nov 2, 2011 at 1:57 PM, Brian Wightman
<MidLifeXis@wightmanfam.org>wrote:

> On Tue, Nov 1, 2011 at 10:17 AM, Eric Schulte <schulte.eric@gmail.com>
> wrote:
> > This is also after all the development repository, and while I do try
> > very hard never to break this head of this repository at the same time I
> > think it is an acceptable place to try out new functionality.
>
> Given that a common recommendation for a bug fix is to 'try commit
> blah blah blah', would it make sense to have bug fixes go onto a
> 'maint' branch (as well as master), and new features / changed
> features stay on the master branch?  At the time when 'master' is
> ready for a new official release, it could then be merged into 'maint'
> to create the next stable point for bug fixes.
>
> Adding features on the same branch as bug fixes, when 'official
> releases' are not made frequently seems to be a formula for
> frustration.
>

Added features are not that much of a problem, but changes which affect
backward compatibility are. But there were not many in the past that I am
aware of.

Cheers,

Rainer



> Thoughts?
>
> Brian
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax (F):       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

[-- Attachment #2: Type: text/html, Size: 2272 bytes --]

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Bastien]

Hi Brian,

Brian Wightman <MidLifeXis@wightmanfam.org> writes:

> Given that a common recommendation for a bug fix is to 'try commit
> blah blah blah', would it make sense to have bug fixes go onto a
> 'maint' branch (as well as master), and new features / changed
> features stay on the master branch?  

Yes, this makes sense, and this has already been suggested.

The reason why I'm not using such a scheme is 1) pure laziness
and 2) the fact that the current git scheme is "good enough".

But it might not be good enough for long, and perhaps future
maintainers will not be as lazy as I am wrt this.

Thanks for the suggestion,

-- 
 Bastien

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Eric Schulte]

>> >
>> > In order to prevent confusion or needless argument: the path I
>> >think we should back off of is the committing of these changes to
>> >master - I think the work should be done in a branch and cooked
>> >thoroughly before merging it to master.
>> >
>>
>
> Partly agree here - I was bitten by the changes, and have suspended work on
> one project until this issue stabilizes - I do not want to change my files
> after each change.
>

Hi Rainer,

In a previous thread in which you were included I suggested a solution
which works now and will continue to work in the future no matter how
this issue is resolved.  That solution is to use a multi-line file local
variable [1] to customize the org-babel-default-header-args variable.  I
should have made a bigger deal of this solution when I posted it the
first time, my apologies.

In general I think we do a good job of not breaking functionality
without on this master branch, and I think that introducing a multitude
of branches would only serve to add confusion, reduce org-wide
cooperation, and ultimately only delay rather than somehow remove them.

Best -- Eric

Footnotes: 
[1]  to see the info page evaluate (info "(elisp)File Local Variables")

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Jambunathan K]

Rainer - if he feels uncomfortable - can choose *not* to update his git
repo and switch his local checkout to a historical version.

> [1]  to see the info page evaluate (info "(elisp)File Local
> Variables")

A usage note for adding these variables without straining the brain.

M-x add-file-local-variable RET
M-x add-file-local-variable-prop-line RET

These commands are documented here.
(info "(emacs) Specifying File Variables")
-- 

Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 1298 bytes --]

Eric: Thanks - but for the moment I will go with Jambunathan's suggestion
and stick with the latest version before the removal of BABEL.

For the record, I created a local branch before the removal of BABEL and
used

git checkout MyBranch

to switch to this branch. So I can keep my local git repo up-to-date and
switch back to master if I want to.
Cheers,

Rainer


On Thu, Nov 3, 2011 at 7:51 PM, Jambunathan K <kjambunathan@gmail.com>wrote:

>
> Rainer - if he feels uncomfortable - can choose *not* to update his git
> repo and switch his local checkout to a historical version.
>
> > [1]  to see the info page evaluate (info "(elisp)File Local
> > Variables")
>
> A usage note for adding these variables without straining the brain.
>
> M-x add-file-local-variable RET
> M-x add-file-local-variable-prop-line RET
>
> These commands are documented here.
> (info "(emacs) Specifying File Variables")
> --
>



-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax (F):       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

[-- Attachment #2: Type: text/html, Size: 1851 bytes --]