obtain ob-template.el for Babel language extension

obtain ob-template.el for Babel language extension

[Joe Riel]

How do I get a copy of ob-template.el?
The file can be viewed at http://orgmode.org/w/worg.git/blob/HEAD:/org-contrib/babel/ob-template.el
however, that is an html file and not the elisp.
I tried using git to clone http://orgmode.org/w/worg.git
but that does not work.

-- 
Joe Riel

Re: obtain ob-template.el for Babel language extension

[Thomas S. Dye]

Aloha Joe,

Joe Riel <joer@san.rr.com> writes:

> How do I get a copy of ob-template.el?
> The file can be viewed at http://orgmode.org/w/worg.git/blob/HEAD:/org-contrib/babel/ob-template.el
> however, that is an html file and not the elisp.
> I tried using git to clone http://orgmode.org/w/worg.git
> but that does not work.

~$ git clone git://orgmode.org/worg.git

You should find ob-template.el in org-contrib/babel/

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

Re: obtain ob-template.el for Babel language extension

[Joe Riel]

On Thu, 10 Sep 2015 20:38:12 -1000
Thomas S. Dye <tsd@tsdye.com> wrote:

> Aloha Joe,
> 
> Joe Riel <joer@san.rr.com> writes:
> 
> > How do I get a copy of ob-template.el?
> > The file can be viewed at http://orgmode.org/w/worg.git/blob/HEAD:/org-contrib/babel/ob-template.el
> > however, that is an html file and not the elisp.
> > I tried using git to clone http://orgmode.org/w/worg.git
> > but that does not work.
> 
> ~$ git clone git://orgmode.org/worg.git
> 
> You should find ob-template.el in org-contrib/babel/

Thanks, that was helpful.  Probably mention of that fact
should be added to the languages.org file---currently it
links directly to the html file which is less useful.

Are elisp files that implement the languages in worg?
I found the *.org files that document them, but not their
sources.


-- 
Joe Riel

Re: obtain ob-template.el for Babel language extension

[Thomas S. Dye]

Aloha Joe,

Joe Riel <joer@san.rr.com> writes:

> On Thu, 10 Sep 2015 20:38:12 -1000
> Thomas S. Dye <tsd@tsdye.com> wrote:
>
>> Aloha Joe,
>> 
>> Joe Riel <joer@san.rr.com> writes:
>> 
>> > How do I get a copy of ob-template.el?
>> > The file can be viewed at http://orgmode.org/w/worg.git/blob/HEAD:/org-contrib/babel/ob-template.el
>> > however, that is an html file and not the elisp.
>> > I tried using git to clone http://orgmode.org/w/worg.git
>> > but that does not work.
>> 
>> ~$ git clone git://orgmode.org/worg.git
>> 
>> You should find ob-template.el in org-contrib/babel/
>
> Thanks, that was helpful.  Probably mention of that fact
> should be added to the languages.org file---currently it
> links directly to the html file which is less useful.

Done.  Thanks.

> Are elisp files that implement the languages in worg?
> I found the *.org files that document them, but not their
> sources.

The language source files are distributed with Org mode.  You can find
them at lisp/ob-*.el.

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

Re: obtain ob-template.el for Babel language extension

[Marco Maggesi]

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

Hi,

I also have a few questions about ob-template.el

1. Can we assume that the HEAD version of ob-template.el is adequate as a
basis for an implementation which is compatible with org version 8.2.xx
(i.e., with older versions of org-mode)?

2. In function org-babel-execute:template functions first, second, third,
etc are used to extract values from processed-params. However, such
function are not defined in elisp, (nth N processed-params) should be used
instead.  Is it correct?
Also, it seems from other examples that the usual approach is to use assoc,
e.g.,  (cdr (assoc ":session" params)). Are there enforced conventions that
ensure the order in processed-params?

3. In function org-babel-expand-body:template we assume that vars is a list
of pairs.  However, it seems to me from some experiments that sometimes
vars contains symbols. Am I wrong?

Thank you,
Marco


Il giorno ven 11 set 2015 alle ore 18:03 Thomas S. Dye <tsd@tsdye.com> ha
scritto:

> Aloha Joe,
>
> Joe Riel <joer@san.rr.com> writes:
>
> > On Thu, 10 Sep 2015 20:38:12 -1000
> > Thomas S. Dye <tsd@tsdye.com> wrote:
> >
> >> Aloha Joe,
> >>
> >> Joe Riel <joer@san.rr.com> writes:
> >>
> >> > How do I get a copy of ob-template.el?
> >> > The file can be viewed at
> http://orgmode.org/w/worg.git/blob/HEAD:/org-contrib/babel/ob-template.el
> >> > however, that is an html file and not the elisp.
> >> > I tried using git to clone http://orgmode.org/w/worg.git
> >> > but that does not work.
> >>
> >> ~$ git clone git://orgmode.org/worg.git
> >>
> >> You should find ob-template.el in org-contrib/babel/
> >
> > Thanks, that was helpful.  Probably mention of that fact
> > should be added to the languages.org file---currently it
> > links directly to the html file which is less useful.
>
> Done.  Thanks.
>
> > Are elisp files that implement the languages in worg?
> > I found the *.org files that document them, but not their
> > sources.
>
> The language source files are distributed with Org mode.  You can find
> them at lisp/ob-*.el.
>
> hth,
> Tom
> --
> Thomas S. Dye
> http://www.tsdye.com
>
>

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

Re: obtain ob-template.el for Babel language extension

[Joe Riel]

On Fri, 11 Sep 2015 19:30:20 +0000
Marco Maggesi <maggesi@math.unifi.it> wrote:

> I also have a few questions about ob-template.el
> 
> 1. Can we assume that the HEAD version of ob-template.el is adequate as a
> basis for an implementation which is compatible with org version 8.2.xx
> (i.e., with older versions of org-mode)?
> 
> 2. In function org-babel-execute:template functions first, second, third,
> etc are used to extract values from processed-params. However, such
> function are not defined in elisp, (nth N processed-params) should be used
> instead.  Is it correct?
> Also, it seems from other examples that the usual approach is to use assoc,
> e.g.,  (cdr (assoc ":session" params)). Are there enforced conventions that
> ensure the order in processed-params?

first, second, etc are macros in cl.el; nothing wrong with that.
However, there is a problem with the usage in the given template.
They are applied to processed-params, and that is not correct because
any variables in the block header are prepended to the list so first,
second, etc are wrong.  The template code should be rewritten.  The
better way to handle this appears to be

  (let ((vars (mapcar #'cdr (org-babel-get-header params :var))))
     ... )


> 3. In function org-babel-expand-body:template we assume that vars is a list
> of pairs.  However, it seems to me from some experiments that sometimes
> vars contains symbols. Am I wrong?

I don't know, but believe it should always contain pairs as vars are required
to have values.  Caveat: I just started playing with this so could be very wrong.

--
Joe Riel

Re: obtain ob-template.el for Babel language extension

[Thomas S. Dye]

Aloha all,

I took the liberty of forwarding Marco's queries to Eric Schulte, the
author of ob-template.el.  Eric no longer maintains Babel or reads the
mailing list, but he replied to the queries as follows:

> Marco Maggesi <maggesi@math.unifi.it> writes:
>
>> Hi,
>>
>> I also have a few questions about ob-template.el
>>
>> 1. Can we assume that the HEAD version of ob-template.el is adequate as a
>> basis for an implementation which is compatible with org version 8.2.xx
>> (i.e., with older versions of org-mode)?
>>

I would look at the latest commit to ob-template, and assume that it was
sufficient to concurrent versions of Org-mode.  Alternate suitable
jumping off points for development of new language extensions would be
the more actively used languages.  Probably ob-shell is the most general
and actively used.

>>
>> 2. In function org-babel-execute:template functions first, second, third,
>> etc are used to extract values from processed-params. However, such
>> function are not defined in elisp, (nth N processed-params) should be used
>> instead.  Is it correct?

This may incorrectly assume that cl.el has been loaded.  This is where
these functions are defined.  They should probably be replaced with the
less intuitive but more portable car, cadr, caddr, etc...

>> 
>> Also, it seems from other examples that the usual approach is to use
>> assoc, e.g., (cdr (assoc ":session" params)). Are there enforced
>> conventions that ensure the order in processed-params?
>>

I'm confused by the two components of this question.  First, yes assoc
is commonly used as params is an association list, however the order of
elements does not matter for an association list.  Second, no the order
of the elements in processed-params is not guaranteed and you should not
write code which makes assumptions about the order of the elements of
this list (it is not mentioned in the documentation string of
`org-babel-process-params').

>>
>> 3. In function org-babel-expand-body:template we assume that vars is a list
>> of pairs.  However, it seems to me from some experiments that sometimes
>> vars contains symbols. Am I wrong?
>>

:var elements in params should always have the following form.

    (:var name . value)

Their cdr should always be a cons cell whose car is the name of the
variable "as a symbol" and whose value is the value of the variable.

I hope this helps,
Eric



Marco Maggesi <maggesi@math.unifi.it> writes:

> Hi,
>
> I also have a few questions about ob-template.el
>
> 1. Can we assume that the HEAD version of ob-template.el is adequate as a
> basis for an implementation which is compatible with org version 8.2.xx
> (i.e., with older versions of org-mode)?
>
> 2. In function org-babel-execute:template functions first, second, third,
> etc are used to extract values from processed-params. However, such
> function are not defined in elisp, (nth N processed-params) should be used
> instead.  Is it correct?
> Also, it seems from other examples that the usual approach is to use assoc,
> e.g.,  (cdr (assoc ":session" params)). Are there enforced conventions that
> ensure the order in processed-params?
>
> 3. In function org-babel-expand-body:template we assume that vars is a list
> of pairs.  However, it seems to me from some experiments that sometimes
> vars contains symbols. Am I wrong?
>
> Thank you,
> Marco
>
>
> Il giorno ven 11 set 2015 alle ore 18:03 Thomas S. Dye <tsd@tsdye.com> ha
> scritto:
>
>> Aloha Joe,
>>
>> Joe Riel <joer@san.rr.com> writes:
>>
>> > On Thu, 10 Sep 2015 20:38:12 -1000
>> > Thomas S. Dye <tsd@tsdye.com> wrote:
>> >
>> >> Aloha Joe,
>> >>
>> >> Joe Riel <joer@san.rr.com> writes:
>> >>
>> >> > How do I get a copy of ob-template.el?
>> >> > The file can be viewed at
>> http://orgmode.org/w/worg.git/blob/HEAD:/org-contrib/babel/ob-template.el
>> >> > however, that is an html file and not the elisp.
>> >> > I tried using git to clone http://orgmode.org/w/worg.git
>> >> > but that does not work.
>> >>
>> >> ~$ git clone git://orgmode.org/worg.git
>> >>
>> >> You should find ob-template.el in org-contrib/babel/
>> >
>> > Thanks, that was helpful.  Probably mention of that fact
>> > should be added to the languages.org file---currently it
>> > links directly to the html file which is less useful.
>>
>> Done.  Thanks.
>>
>> > Are elisp files that implement the languages in worg?
>> > I found the *.org files that document them, but not their
>> > sources.
>>
>> The language source files are distributed with Org mode.  You can find
>> them at lisp/ob-*.el.
>>
>> hth,
>> Tom
>> --
>> Thomas S. Dye
>> http://www.tsdye.com
>>
>>

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

Re: obtain ob-template.el for Babel language extension

[Joe Riel]

On Mon, 14 Sep 2015 16:37:04 -1000
Thomas S. Dye <tsd@tsdye.com> wrote:

> Aloha all,
> 
> I took the liberty of forwarding Marco's queries to Eric Schulte, the
> author of ob-template.el.  Eric no longer maintains Babel or reads the
> mailing list, but he replied to the queries as follows:
> 
> > Marco Maggesi <maggesi@math.unifi.it> writes:
> >
> >> Hi,
> >>
> >> I also have a few questions about ob-template.el
> >>
> >> 1. Can we assume that the HEAD version of ob-template.el is adequate as a
> >> basis for an implementation which is compatible with org version 8.2.xx
> >> (i.e., with older versions of org-mode)?
> >>
> 
> I would look at the latest commit to ob-template, and assume that it was
> sufficient to concurrent versions of Org-mode.  Alternate suitable
> jumping off points for development of new language extensions would be
> the more actively used languages.  Probably ob-shell is the most general
> and actively used.
> 
> >>
> >> 2. In function org-babel-execute:template functions first, second, third,
> >> etc are used to extract values from processed-params. However, such
> >> function are not defined in elisp, (nth N processed-params) should be used
> >> instead.  Is it correct?
> 
> This may incorrectly assume that cl.el has been loaded.  This is where
> these functions are defined.  They should probably be replaced with the
> less intuitive but more portable car, cadr, caddr, etc...
> 
> >> 
> >> Also, it seems from other examples that the usual approach is to use
> >> assoc, e.g., (cdr (assoc ":session" params)). Are there enforced
> >> conventions that ensure the order in processed-params?
> >>
> 
> I'm confused by the two components of this question.  First, yes assoc
> is commonly used as params is an association list, however the order of
> elements does not matter for an association list.  Second, no the order
> of the elements in processed-params is not guaranteed and you should not
> write code which makes assumptions about the order of the elements of
> this list (it is not mentioned in the documentation string of
> `org-babel-process-params').

The questions were related.  The real problem, as I pointed out previously,
is that using first, second (or car, etc) doesn't work because it assumes
an ordering that doesn't exist, as Eric notes.  As such, ob-template.el 
is broken and should be replaced.  If I get some cycles I'll push a
patch.

> 
> >>
> >> 3. In function org-babel-expand-body:template we assume that vars is a list
> >> of pairs.  However, it seems to me from some experiments that sometimes
> >> vars contains symbols. Am I wrong?
> >>
> 
> :var elements in params should always have the following form.
> 
>     (:var name . value)
> 
> Their cdr should always be a cons cell whose car is the name of the
> variable "as a symbol" and whose value is the value of the variable.
> 
> I hope this helps,
> Eric
> 
> 
> 
> Marco Maggesi <maggesi@math.unifi.it> writes:
> 
> > Hi,
> >
> > I also have a few questions about ob-template.el
> >
> > 1. Can we assume that the HEAD version of ob-template.el is adequate as a
> > basis for an implementation which is compatible with org version 8.2.xx
> > (i.e., with older versions of org-mode)?
> >
> > 2. In function org-babel-execute:template functions first, second, third,
> > etc are used to extract values from processed-params. However, such
> > function are not defined in elisp, (nth N processed-params) should be used
> > instead.  Is it correct?
> > Also, it seems from other examples that the usual approach is to use assoc,
> > e.g.,  (cdr (assoc ":session" params)). Are there enforced conventions that
> > ensure the order in processed-params?
> >
> > 3. In function org-babel-expand-body:template we assume that vars is a list
> > of pairs.  However, it seems to me from some experiments that sometimes
> > vars contains symbols. Am I wrong?
> >
> > Thank you,
> > Marco
> >
> >
> > Il giorno ven 11 set 2015 alle ore 18:03 Thomas S. Dye <tsd@tsdye.com> ha
> > scritto:
> >
> >> Aloha Joe,
> >>
> >> Joe Riel <joer@san.rr.com> writes:
> >>
> >> > On Thu, 10 Sep 2015 20:38:12 -1000
> >> > Thomas S. Dye <tsd@tsdye.com> wrote:
> >> >
> >> >> Aloha Joe,
> >> >>
> >> >> Joe Riel <joer@san.rr.com> writes:
> >> >>
> >> >> > How do I get a copy of ob-template.el?
> >> >> > The file can be viewed at
> >> http://orgmode.org/w/worg.git/blob/HEAD:/org-contrib/babel/ob-template.el
> >> >> > however, that is an html file and not the elisp.
> >> >> > I tried using git to clone http://orgmode.org/w/worg.git
> >> >> > but that does not work.
> >> >>
> >> >> ~$ git clone git://orgmode.org/worg.git
> >> >>
> >> >> You should find ob-template.el in org-contrib/babel/
> >> >
> >> > Thanks, that was helpful.  Probably mention of that fact
> >> > should be added to the languages.org file---currently it
> >> > links directly to the html file which is less useful.
> >>
> >> Done.  Thanks.
> >>
> >> > Are elisp files that implement the languages in worg?
> >> > I found the *.org files that document them, but not their
> >> > sources.
> >>
> >> The language source files are distributed with Org mode.  You can find
> >> them at lisp/ob-*.el.
> >>
> >> hth,
> >> Tom
> >> --
> >> Thomas S. Dye
> >> http://www.tsdye.com
> >>
> >>
> 



-- 
Joe Riel

Re: obtain ob-template.el for Babel language extension

[Joe Riel]

On Fri, 11 Sep 2015 06:03:32 -1000
Thomas S. Dye <tsd@tsdye.com> wrote:

> Aloha Joe,
> 
> Joe Riel <joer@san.rr.com> writes:
> 
> > On Thu, 10 Sep 2015 20:38:12 -1000
> > Thomas S. Dye <tsd@tsdye.com> wrote:
> >
> >> Aloha Joe,
> >> 
> >> Joe Riel <joer@san.rr.com> writes:
> >> 
> >> > How do I get a copy of ob-template.el?
> >> > The file can be viewed at http://orgmode.org/w/worg.git/blob/HEAD:/org-contrib/babel/ob-template.el
> >> > however, that is an html file and not the elisp.
> >> > I tried using git to clone http://orgmode.org/w/worg.git
> >> > but that does not work.
> >> 
> >> ~$ git clone git://orgmode.org/worg.git
> >> 
> >> You should find ob-template.el in org-contrib/babel/
> >
> > Thanks, that was helpful.  Probably mention of that fact
> > should be added to the languages.org file---currently it
> > links directly to the html file which is less useful.
> 
> Done.  Thanks.
> 
> > Are elisp files that implement the languages in worg?
> > I found the *.org files that document them, but not their
> > sources.
> 
> The language source files are distributed with Org mode.  You can find
> them at lisp/ob-*.el.

Thanks.  

No offense, but the help pages on the code blocks could really use
improvement.  For example,

Exporting code blocks
---------------------
Nowhere does this section explain *how* you can export a code block,
nor are there any links to pages that are helpful.  As a minimum it
should include the relevant commands and the key bindings for
exporting code blocks.  Where are they?

Evaluating code blocks
----------------------
The second paragraph states that only 'emacs-lisp' is enabled by
default.  Suppose I want to use something other than 'emacs-lisp',
*how* do I enable that?  The parenthetical comment states that the
Languages section lists the supoported languages but doesn't mention
that the explanation of enabling other languages is there.  Better
to not leave the reader hanging.  How about this:

"By default, the evaluation facility is only enabled for Lisp code
blocks specified as ‘emacs-lisp’.  See _Languages_ for instructions on
enabling other languages and for a list of supported languages.  See
_Structure of code blocks_ for information on the syntax used to
define a code block."





-- 
Joe Riel

Re: obtain ob-template.el for Babel language extension

[Thomas S. Dye]

Aloha Joe,

Joe Riel <joer@san.rr.com> writes:
>
> No offense, but the help pages on the code blocks could really use
> improvement.

Glad to have your help.  The documentation is a community effort.

> For example,
>
> Exporting code blocks
> ---------------------
> Nowhere does this section explain *how* you can export a code block,
> nor are there any links to pages that are helpful.  As a minimum it
> should include the relevant commands and the key bindings for
> exporting code blocks.  Where are they?

Typically, one doesn't export a code block by itself.  Instead, one
exports a document that includes one or more code blocks.  How to export
a document is covered in Chapter 12, Exporting.

> Evaluating code blocks
> ----------------------
> The second paragraph states that only 'emacs-lisp' is enabled by
> default.  Suppose I want to use something other than 'emacs-lisp',
> *how* do I enable that?  The parenthetical comment states that the
> Languages section lists the supoported languages but doesn't mention
> that the explanation of enabling other languages is there.  Better
> to not leave the reader hanging.  How about this:
>
> "By default, the evaluation facility is only enabled for Lisp code
> blocks specified as ‘emacs-lisp’.  See _Languages_ for instructions on
> enabling other languages and for a list of supported languages.  See
> _Structure of code blocks_ for information on the syntax used to
> define a code block."

I think this is an improvement.  IMHO it is almost always a good thing
to get rid of parenthetical statements.  Would you like to submit a
patch for org.texi?  You'll find instructions here:
http://orgmode.org/worg/org-contribute.html#orgheadline1

Another problem is the outdated list of supported languages in Section
14.7, Languages.  Perhaps this could be replaced by a pointer to the
more complete list maintained on Worg?  Should this section distinguish
the various levels of "support", e.g. core, contrib, and packages?

All the best,
Tom

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

Re: obtain ob-template.el for Babel language extension

[Joe Riel]

On Sat, 12 Sep 2015 07:15:37 -1000
Thomas S. Dye <tsd@tsdye.com> wrote:

> Aloha Joe,
> 
> Joe Riel <joer@san.rr.com> writes:
> >
> > No offense, but the help pages on the code blocks could really use
> > improvement.
> 
> Glad to have your help.  The documentation is a community effort.

Agreed.  Because I'm new to this aspect of org, I'm reading the
relevant manual pages for the first time.  As such, it is easy
to note deficiencies.  I'll help to improve them. 

> 
> > For example,
> >
> > Exporting code blocks
> > ---------------------
> > Nowhere does this section explain *how* you can export a code block,
> > nor are there any links to pages that are helpful.  As a minimum it
> > should include the relevant commands and the key bindings for
> > exporting code blocks.  Where are they?
> 
> Typically, one doesn't export a code block by itself.  Instead, one
> exports a document that includes one or more code blocks.  How to export
> a document is covered in Chapter 12, Exporting.

I figured that out eventually.  There should be a link from the
exporting code blocks section to chapter 12; not everyone reads manual
in a linear fashion 8-).  I'll submit that with the other suggestion
(below).

> > Evaluating code blocks
> > ----------------------
> > The second paragraph states that only 'emacs-lisp' is enabled by
> > default.  Suppose I want to use something other than 'emacs-lisp',
> > *how* do I enable that?  The parenthetical comment states that the
> > Languages section lists the supoported languages but doesn't mention
> > that the explanation of enabling other languages is there.  Better
> > to not leave the reader hanging.  How about this:
> >
> > "By default, the evaluation facility is only enabled for Lisp code
> > blocks specified as ‘emacs-lisp’.  See _Languages_ for instructions on
> > enabling other languages and for a list of supported languages.  See
> > _Structure of code blocks_ for information on the syntax used to
> > define a code block."
> 
> I think this is an improvement.  IMHO it is almost always a good thing
> to get rid of parenthetical statements.  Would you like to submit a
> patch for org.texi?  You'll find instructions here:
> http://orgmode.org/worg/org-contribute.html#orgheadline1
> 
> Another problem is the outdated list of supported languages in Section
> 14.7, Languages.  Perhaps this could be replaced by a pointer to the
> more complete list maintained on Worg?  Should this section distinguish
> the various levels of "support", e.g. core, contrib, and packages?
> 
> All the best,
> Tom
> 



-- 
Joe Riel

[PATCH] small improvements to info page, Working with source code

[Joe Riel]

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

The attached two patches make small improvements to
the "Working with source code".  

This is my first time submitting patches to org, it's
not entirely clear that I'm doing this correctly
(i.e. sending them to the correct place).



-- 
Joe Riel


[-- Attachment #2: 0001-doc-org.texi-Evaluating-code-blocks-Rewrite-paragrap.patch --]
[-- Type: text/x-patch, Size: 1247 bytes --]

From 2dad38f55c6c2e1dbe37eb7c5cdad94f5ed94ca9 Mon Sep 17 00:00:00 2001
From: Joe Riel <jriel@maplesoft.com>
Date: Sat, 12 Sep 2015 11:30:06 -0700
Subject: [PATCH 1/2] * doc/org.texi: (Evaluating code blocks) Rewrite
 paragraph to state where to find information on enabling other languages.

---
 doc/org.texi | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index ac7d3a4..1e67b62 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -14972,10 +14972,9 @@ and/or the name of the evaluated code block.  The default value of
 @code{org-babel-results-keyword}.
 
 By default, the evaluation facility is only enabled for Lisp code blocks
-specified as @code{emacs-lisp}.  However, source code blocks in many languages
-can be evaluated within Org mode (see @ref{Languages} for a list of supported
-languages and @ref{Structure of code blocks} for information on the syntax
-used to define a code block).
+specified as @code{emacs-lisp}.  See @ref{Languages} to enable other
+supported languages.  See @ref{Structure of code blocks} for information on
+the syntax used to define a code block.
 
 @kindex C-c C-c
 There are a number of ways to evaluate code blocks.  The simplest is to press
-- 
2.1.4


[-- Attachment #3: 0002-doc-org.texi-Exporting-code-blocks-add-link-to-Expor.patch --]
[-- Type: text/x-patch, Size: 1151 bytes --]

From af923060170cdaba9eaa6701d0e8175837429d84 Mon Sep 17 00:00:00 2001
From: Joe Riel <jriel@maplesoft.com>
Date: Sat, 12 Sep 2015 11:36:50 -0700
Subject: [PATCH 2/2] * doc/org.texi: (Exporting code blocks) add link to
 Exporting

Coming into this section without having read the chapter 12
is pretty confusing.  The link is helpful.
---
 doc/org.texi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/doc/org.texi b/doc/org.texi
index 1e67b62..c630c7a 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -14851,7 +14851,8 @@ of code block evaluation, @emph{both} the code and the results of code block
 evaluation, or @emph{none}.  For most languages, the default exports code.
 However, for some languages (e.g., @code{ditaa}) the default exports the
 results of code block evaluation.  For information on exporting code block
-bodies, see @ref{Literal examples}.
+bodies, see @ref{Literal examples}.  For information on exporting
+parts of Org documents, see @ref{Exporting}.
 
 The @code{:exports} header argument can be used to specify export
 behavior (note that these arguments are only relevant for code blocks, not
-- 
2.1.4

Re: [PATCH] small improvements to info page, Working with source code; add TINYCHANG

[Joe Riel]

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

On Sat, 12 Sep 2015 11:50:23 -0700
Joe Riel <joer@san.rr.com> wrote:

> The attached two patches make small improvements to
> the "Working with source code".  
> 
> This is my first time submitting patches to org, it's
> not entirely clear that I'm doing this correctly
> (i.e. sending them to the correct place).

The attached patches replace the previous.
The patches are identical, these add TINYCHANGE to the
commit messages.

 



-- 
Joe Riel


[-- Attachment #2: 0001-doc-org.texi-Rewrite-paragraph.patch --]
[-- Type: text/x-patch, Size: 1335 bytes --]

From 358ec72642b091b0cc8e8ce87d5525f2dbd1e8ec Mon Sep 17 00:00:00 2001
From: Joe Riel <jriel@maplesoft.com>
Date: Sat, 12 Sep 2015 11:30:06 -0700
Subject: [PATCH 1/3] doc/org.texi: Rewrite paragraph

doc/org.texi (Evaluating code blocks):

Rewrite paragraph to state where to find information on enabling other
languages.  Without this, it isn't clear where to look.

TINYCHANGE.
---
 doc/org.texi | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index ac7d3a4..1e67b62 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -14972,10 +14972,9 @@ and/or the name of the evaluated code block.  The default value of
 @code{org-babel-results-keyword}.
 
 By default, the evaluation facility is only enabled for Lisp code blocks
-specified as @code{emacs-lisp}.  However, source code blocks in many languages
-can be evaluated within Org mode (see @ref{Languages} for a list of supported
-languages and @ref{Structure of code blocks} for information on the syntax
-used to define a code block).
+specified as @code{emacs-lisp}.  See @ref{Languages} to enable other
+supported languages.  See @ref{Structure of code blocks} for information on
+the syntax used to define a code block.
 
 @kindex C-c C-c
 There are a number of ways to evaluate code blocks.  The simplest is to press
-- 
2.1.4


[-- Attachment #3: 0002-doc-org.texi-add-link-to-relevant-chapter.patch --]
[-- Type: text/x-patch, Size: 1206 bytes --]

From 29679d5e5854e9a2ff0e41af92c451ccdcd82f73 Mon Sep 17 00:00:00 2001
From: Joe Riel <jriel@maplesoft.com>
Date: Sat, 12 Sep 2015 11:36:50 -0700
Subject: [PATCH 2/3] doc/org.texi: add link to relevant chapter

* doc/org.texi (Exporting code blocks) add link to Exporting

Coming into this section without having read the chapter 12
is pretty confusing.  The link is helpful.

TINYCHANGE.
---
 doc/org.texi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/doc/org.texi b/doc/org.texi
index 1e67b62..c630c7a 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -14851,7 +14851,8 @@ of code block evaluation, @emph{both} the code and the results of code block
 evaluation, or @emph{none}.  For most languages, the default exports code.
 However, for some languages (e.g., @code{ditaa}) the default exports the
 results of code block evaluation.  For information on exporting code block
-bodies, see @ref{Literal examples}.
+bodies, see @ref{Literal examples}.  For information on exporting
+parts of Org documents, see @ref{Exporting}.
 
 The @code{:exports} header argument can be used to specify export
 behavior (note that these arguments are only relevant for code blocks, not
-- 
2.1.4

Re: [PATCH] small improvements to info page, Working with source code; add TINYCHANG

[Rasmus]

Joe Riel <joer@san.rr.com> writes:

> On Sat, 12 Sep 2015 11:50:23 -0700
> Joe Riel <joer@san.rr.com> wrote:
>
>> The attached two patches make small improvements to
>> the "Working with source code".  
>> 
>> This is my first time submitting patches to org, it's
>> not entirely clear that I'm doing this correctly
>> (i.e. sending them to the correct place).
>
> The attached patches replace the previous.
> The patches are identical, these add TINYCHANGE to the
> commit messages.

Pushed.  Thanks.

-- 
However beautiful the theory, you should occasionally look at the evidence