Re: [O] org.texi edits, patch attached

[Nicolas Goaziou]

Nicolas Goaziou  writes:

> Lambda Coder  writes:
>
>> See attached patch for Exporting chapter against maint. 
>
> Thank you. 
>
> Unfortunately, I cannot apply it. Could you send create it with
> format-patch against maint's tip, without gzipping it?

Out of curiosity, did you make any progress on it? 

I still cannot merge your work and I wouldn't want it to be lost.

Thank you.

Re: [O] org.texi edits, patch attached

[Nicolas Goaziou]

Hello,

Lambda Coder  writes:

> See attached patch for Exporting chapter against maint. 

Thank you. 

Unfortunately, I cannot apply it. Could you send create it with
format-patch against maint's tip, without gzipping it?

> Also my notes to your comments.

Answers follow.

>> +Org has export facilities for printing, format conversions, and general
>> +sharing of Org documents with the outside world.  Org export supports
>> +pretty-printing, web publishing, slide shows, and quick exports of lists and
>> +tables to many foreign formats while retaining as much structure
>> +(@pxref{Document structure}) and markup (@pxref{Markup}) as possible.  The
>> +many features of Org exports are constantly being improved and expanded and
>> +they are all explained in this chapter.
> 
> I would remove "are constantly being improved and expanded and they"
> 
> [why?]

It sounds like a commercial ad.

> Shouldn't we leave that for a docstring?
> 
> [Perhaps, but all three conditions have to be together.]

Fair enough.

>> +@example
>> +#+ATTR_BEAMER: :options [Lagrange]
>> +Let $G$ be a finite group, and let $H$ be
>> +a subgroup of $G$.  Then the order of $H$ divides the order of $G$.
>> +@end example
> 
> The example above does nothing useful, does it? :options do not apply to
> paragraphs AFAIK.
> 
> [I did not put it there, edit it as you see fit.]

OK, will do, if I remember about it.

>> +Options for MathJax (@code{org-html-mathjax-options}).  MathJax is used to
>> +typeset @LaTeX{} math in HTML documents.  @ref{Math formatting in HTML
>> +export} has an example.
> 
>   @xref{Math formatting in HTML export}, for an example.
> 
> [commas don't make grammatical sense here after xref]

It is not about English grammar, but about Texinfo syntax.

  @xref{whatever}, for example.

produces

  See Section 3.1 [whatever], page 24, for example.

whereas

  @xref{whatever} for example.

produces

  See Section 3.1 [whatever], page 24 for example.

which is awkward.

>>  #+BEGIN_SRC emacs-lisp
>> -  (defun Fib (n)  ; Count rabbits.
>> +  (defun Fib (n)
>>  (if (< n 2) n (+ (Fib (- n 1)) (Fib (- n 2)
>>  #+END_SRC
> 
> You ruined the joke :)
> 
> ["count rabbit pairs" makes it more accurate but still nothing funny]

Too bad. I found it hilarious (!). Let's remove it then.

>>  @example
>> -#+attr_texinfo: :options org-org-export-to-org ...
>> +#+attr_texinfo: :options opt1 opt2 opt3 ...
>>  #+begin_defun
>>  A somewhat obsessive function.
>>  #+end_defun
>>  @end example
> 
> You also ruined the joke :) You need to replace the contents of the
> defun, which do not make sense anymore.
> 
> [I did not know that was a joke.]

Ah well. I find names following specific schemes funny, at times.

> Also, #+begin_defun expects a function name, not arguments.
> 
> [That's what I thought but see the original block was like that without 
> options]

The original is correct since it provides a name for the function being
defined.

>>  @noindent
>> -becomes
>> +exports to
>>=20=20
>>  @example
>> -@@defun org-org-export-to-org ...
>> +@@defun opt1 opt2 opt3 ...
>>  A somewhat obsessive function.
>>  @@end defun
>>  @end example
> 
> Ditto.
> 
> [Restored the previous example. Strongly suggest re-editing this
> example or removing it entirely. It's neither informative nor funny.]

You may not find it funny, but it's definitely informative, since it
illustrates the :options attribute.


Regards,

-- 
Nicolas Goaziou

Re: [O] org.texi edits, patch attached

[Lambda Coder]

On Sun, Dec 18, 2016 at 3:39 PM, Nicolas Goaziou 
wrote:

> Could you send an updated patch?
>
>
> Regards,
>
> --
> Nicolas Goaziou
>


See attached patch for Exporting chapter against maint. Also my notes to
your comments.

--Lambda Coder.


0002-Editorial-revisions-to-the-manual.patch.gz
Description: GNU Zip compressed data


20161219CommentsFromNicolas.txt.gz
Description: GNU Zip compressed data

Re: [O] org.texi edits, patch attached

[Nicolas Goaziou]

Hello,

Lambda Coder  writes:

> I have more. I've just finished the Exporting chapter. See the attached
> patch file against current maint branch.

Thank you!

Usual comments and questions follow.

> +Org has export facilities for printing, format conversions, and general
> +sharing of Org documents with the outside world.  Org export supports
> +pretty-printing, web publishing, slide shows, and quick exports of lists and
> +tables to many foreign formats while retaining as much structure
> +(@pxref{Document structure}) and markup (@pxref{Markup}) as possible.  The
> +many features of Org exports are constantly being improved and expanded and
> +they are all explained in this chapter.

I would remove "are constantly being improved and expanded and they"

> +@noindent Org also uses additional libraries located in @code{contrib/}
> +directory (@pxref{Installation}).  Users can install even more specialized
> +libraries from the Emacs packaging system.  

Nitpick: libraries from the Emacs packaging system may not be "more
specialized", but just different.

What about dropping "specialized"?

> +Invokes the export dispatcher interface.  The options show default settings.
> +The @kbd{C-u} prefix argument preserves options from the previous export,
> +including any sub-tree selections as long as buffer contents have not changed
> +since the last export.

The last part of the sentence above is incorrect. Buffer contents may
have changed between two exports. Otherwise, there is not much interest
in exporting the same thing twice, even with a shortcut.

> -Toggle subtree export.  The top heading becomes the document title.
> +Toggle sub-tree export.  When turned on, Org exports only the sub-tree 
> starting
> +from the cursor position at the time the export dispatcher was invoked.  Org
> +uses the top heading of this sub-tree as the document's title.  If the cursor
> +is not on a heading, Org uses the nearest enclosing header.  If the cursor is
> +in the document preamble, Org signals an error and aborts export.

I wonder if the last sentence isn't too technical for a manual.
Shouldn't we leave that for a docstring?

> +Options set through properties
> +(@pxref{Properties and columns}) apply to that specific heading and its
> +subheadings.  Properties are inherited in the hierarchy, and, in case of
> +overlap, options set at the specific level override those set at the more
> +general and global levels.

This is not correct. Options set through properties apply only when
doing a sub-tree export. Besides, even in this case, properties are not
necessarily inherited. It depens on `org-use-property-inheritance'.

> -A date or a time-stamp@footnote{The variable
> -@code{org-export-date-timestamp-format} defines how this time-stamp will be
> -exported.}.
> +A date or a time-stamp@footnote{The export format is specified in 
> +@code{org-export-date-timestamp-format}.}.

`org-export-date-timestamp-format' has an effect only when DATE is
a time-stamp. It isn't obvious by reading the above.

>  @item EMAIL
>  @cindex #+EMAIL
> @@ -10436,46 +10465,47 @@ The email address (@code{user-mail-address}).
>  @item LANGUAGE
>  @cindex #+LANGUAGE
>  @vindex org-export-default-language
> -The language used for translating some strings
> -(@code{org-export-default-language}).  E.g., @samp{#+LANGUAGE: fr} will tell
> -Org to translate @emph{File} (english) into @emph{Fichier} (french) in the
> -clocktable.
> +Language to use for translating certain strings
> +(@code{org-export-default-language}).  With @samp{#+LANGUAGE: fr}, for
> +example for the clocktable, Org translates the English @emph{File} to the
> +French @emph{Fichier}.

The example needs to be changed (so did the old one).
`org-export-default-language' has no effect on the Clock Table.
I suggest to replace it with a real example, e.g.

  With @samp{#+LANGUAGE: fr}, for example, Org translates @emph{Table of
  contents} to the French @emph{Table des matières}.

> +The default value is @code{:export:}.  When a tree is tagged with
> +@code{:export:} (@code{org-export-select-tags}), Org selects that tree and
> +its sub-trees for export.  Org excludes trees with @code{:noexport:} tags 
> (see
> +below).  

Usual nitpick:

  tags---see below.

> -Toggle inclusion of drawers, or list drawers to include
> +Toggle inclusion of drawers, or list-drawers to include

Is this a typo? `org-export-with-drawers' can contain a list of drawers
to include (or not).

> +``Planning information'' comes from lines containing any combination of these
> +cookies: @code{SCHEDULED:}, @code{DEADLINE:}, or @code{CLOSED:}.

and located right after the headline.

> +Org converts the first three outline levels into headlines for ASCII export.
> +The remaining levels are turned into lists.  To change this cut-off point
> +where levels become lists, (@pxref{Export settings}).

You should remove the parenthesis above.

>  @subheading Quoting ASCII text
>  
> -You can insert text that will 

Re: [O] org.texi edits, patch attached

[Lambda Coder]

Thanks.

I have more. I've just finished the Exporting chapter. See the attached
patch file against current maint branch.

Best wishes,

--Lambda Coder.

On Sat, Dec 3, 2016 at 3:46 PM, Nicolas Goaziou 
wrote:

> Hello,
>
> Lambda Coder  writes:
>
> > See the attached patch file diff'd against maint.
>
> Applied. Thank you for all that work.
>
> Regards,
>
> --
> Nicolas Goaziou
>


0001-Editorial-revisions-to-the-manual.patch.gz
Description: GNU Zip compressed data

Re: [O] org.texi edits, patch attached

[Nicolas Goaziou]

Hello,

Lambda Coder  writes:

> See the attached patch file diff'd against maint.

Applied. Thank you for all that work.

Regards,

-- 
Nicolas Goaziou

Re: [O] org.texi edits, patch attached

[Lambda Coder]

On Sat, Nov 26, 2016 at 2:42 PM, Nicolas Goaziou 
wrote:

>
> Could you send an updated patch?
>
> Regards,
>
> --
> Nicolas Goaziou
>


See the attached patch file diff'd against maint. I've also attached a
separate file that has your comments and my responses. Hope they are
self-explanatory.

--Lambda Coder.


0001-doc-org-texi.patch.gz
Description: GNU Zip compressed data


20161123CommentsFromNicolas.txt.gz
Description: GNU Zip compressed data

Re: [O] org.texi edits, patch attached

[Nicolas Goaziou]

Hello,

Lambda Coder  writes:

> Nicolas, attached is the revised edits for:
>
> * Working with source code (2nd review)
> * Miscellaneous
> * Hacking
> * MobileOrg
>
> The patch is against maint branch from today.

Thank you. Some comments and suggestions follow.

Before starting however, I have one question: isn't replacing "code
block" with "src code block" everywhere a bit obnoxious? Couldn't define
once and for all that a "src block" is a code block and simply use "code
block" everywhere?

Also, your patch inserts trailing white spaces throughout the document.
Could you double-check that?

> +Org can flexibly export just the @emph{code} from the @samp{src} code blocks,
> +just the @emph{results} of evaluation of the @samp{src} code block,
> +@emph{both} the code and the results of @samp{src} code block evaluation, or
> +@emph{none}.  Org defaults to exporting @emph{code} for most languages.  For
> +some languages, such as @code{ditaa}, Org defaults to @emph{results}.  Each
> +of these options is described below.  For details about exporting just the
> +body of @samp{src} code blocks, see @ref{Literal examples}.  For details
> +about exporting portions (sub-trees) of an Org document, see
> @ref{Exporting}

  code blocks, @pxref{Literal examples}.

and,

  Org document, @pxref{Exporting}.

also,

  about exporting parts of an Org document 

i.e., drop "sub-trees", "portions" and the parenthesis.

> -The @code{:exports} header arguments control the export of code blocks (and
> -not inline code):
> +The @code{:exports} header arguments control the export of @samp{src} code
> +blocks (and not inline code):

  code blocks---and not inline code:

> -After each evaluation, results are inserted after the end of code block in
> -the Org buffer.  Previous results are either replaced (default) or appended
> -to.  On export, Org includes only the results and not the code block.
> +After each evaluation, Org inserts the results at the end of @samp{src} code
> +block in the Org buffer.  Previous results are either replaced (default) or
> +appended to.  On export, Org includes only the results and not the @samp{src}
> +code block.

  replaced---which is the default---or appended to...

>  @vindex org-export-use-babel
> -To stop Org from evaluating code blocks during export, set
> -@code{org-export-use-babel} variable to @code{nil}.  Turning off evaluation
> -comes in handy when batch processing.  For example, markup languages for
> -wikis, which have a high risk of untrusted code.  In this case, Org doesn't
> -process header arguments either.  For this reason it is often better to set
> -@code{:eval never-export} (@pxref{eval}) to prevent code evaluation but still
> -allow headers to be honored.  To evaluate just the inline code blocks, set to
> -@code{inline-only}.  Isolating inline evaluations is not for security but for
> -avoiding any delays due to recalculations during exports, such as calls to
> -a remote database.
> -
> -Org never evaluates code blocks in commented sub-trees when exporting
> -(@pxref{Comment lines}).  On the other hand, Org does evaluate code blocks in
> -sub-trees excluded from export (@pxref{Export settings}).
> +
> +To stop Org from evaluating @samp{src} code blocks during export, set
> +@code{org-export-babel-evaluate} variable to @code{nil}.  Stopping evaluation
> +comes in handy when batch processing in environments with high risk of
> +untrusted code, such as markup languages for wikis.  To evaluate only the
> +inline @samp{src} code blocks, set the variable to @code{inline-only}.  This
> +isolates evaluation not for any security reasons but for avoiding delays due
> +to recalculations during exports, such as calls to a remote database.
> +
> +Org never evaluates @samp{src} code blocks in commented sub-trees when
> +exporting (@pxref{Comment lines}).  On the other hand, Org does evaluate
> +@samp{src} code blocks in sub-trees excluded from export (@pxref{Export
> +settings}).

There is a gotcha here. This part was modified in master. It would be
better to preserve as much as possible the parts of the original text,
in particular the reference to ":eval no-export".

I suggest to find a common paragraph, simply replacing
`org-export-use-babel' with `org-export-babel-evaluate' for maint branch.

> -them in the Org file, right after the @samp{src} code block.  The insertion
> -point is after a newline and the @code{#+RESULTS} label.  Org creates the
> -@code{#+RESULTS} label if one is not already there.
> +them in the Org file, immediately following the @samp{src} code block.  The
> +insertion point is after a newline and the @code{#+RESULTS} label.  Org
> +creates the @code{#+RESULTS} label if one is not already there.
>  
> -By default, Org enables only @code{emacs-lisp} source code blocks for
> -execution.  See @ref{Languages} for identifiers to enable other languages.
> +By default, Org enables execution for only @code{emacs-lisp} @samp{src} code
> +blocks.  To add 

Re: [O] org.texi edits, patch attached

[Lambda Coder]

Nicolas, attached is the revised edits for:

* Working with source code (2nd review)
* Miscellaneous
* Hacking
* MobileOrg

The patch is against maint branch from today.

Best wishes,

--Lambda Coder

On Fri, Nov 18, 2016 at 8:09 PM, Lambda Coder  wrote:

> Thanks Nicolas for pushing the 1st set of edits.
>
> Attached I have a 2nd set of edits for the same chapter. Cleaned up
> references mainly.
>
> This patch is based off maint branch. Hope it's easier for you this time.
>
> Best wishes,
>
> --Lambda Coder
>
>
> On Fri, Nov 18, 2016 at 12:21 AM, Nicolas Goaziou 
> wrote:
>
>> Hello,
>>
>> Lambda Coder  writes:
>>
>> > Do you prefer future edits against master or maint branch? It was not
>> clear
>> > when I asked the very first time.
>>
>> Documentation fixes usually go to maint, unless they refer to
>> a master-only feature, obviously.
>>
>> Regards,
>>
>> --
>> Nicolas Goaziou
>>
>
>


0001.patch.gz
Description: GNU Zip compressed data

Re: [O] org.texi edits, patch attached

[Lambda Coder]

Thanks Nicolas for pushing the 1st set of edits.

Attached I have a 2nd set of edits for the same chapter. Cleaned up
references mainly.

This patch is based off maint branch. Hope it's easier for you this time.

Best wishes,

--Lambda Coder


On Fri, Nov 18, 2016 at 12:21 AM, Nicolas Goaziou 
wrote:

> Hello,
>
> Lambda Coder  writes:
>
> > Do you prefer future edits against master or maint branch? It was not
> clear
> > when I asked the very first time.
>
> Documentation fixes usually go to maint, unless they refer to
> a master-only feature, obviously.
>
> Regards,
>
> --
> Nicolas Goaziou
>


0001-Working-with-source-code-2nd-revision.patch.gz
Description: GNU Zip compressed data

Re: [O] org.texi edits, patch attached

[Nicolas Goaziou]

Hello,

Lambda Coder  writes:

> Do you prefer future edits against master or maint branch? It was not clear
> when I asked the very first time.

Documentation fixes usually go to maint, unless they refer to
a master-only feature, obviously.

Regards,

-- 
Nicolas Goaziou

Re: [O] org.texi edits, patch attached

[Lambda Coder]

On Thu, Nov 17, 2016 at 2:56 PM, Nicolas Goaziou 
wrote:

> It didn't so I used the latter and applied your changes. I also added
> a changelog.
>

Thanks.

Do you prefer future edits against master or maint branch? It was not clear
when I asked the very first time.

--Lambda Coder.

Re: [O] org.texi edits, patch attached

[Nicolas Goaziou]

Hello,

Lambda Coder  writes:

> See if this patch file works. It was generated against maint branch instead
> of master with this command:
>
> git format-patch origin/maint
>
> If it still does not work for you, use the attached the org.texi file
> instead. Just copy the entire Working With Source Code chapter.

It didn't so I used the latter and applied your changes. I also added
a changelog.

Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] org.texi edits, patch attached

[Nicolas Goaziou]

Hello,

Lambda Coder  writes:

> Yes, see attached patch 2.

Thank you.

I have one last suggestion below.

Also, I cannot apply it to maint branch. Could you try rebasing maint
and format patch from there?

> +directory} is not expanded---due to portability issues.

I suggest instead:

  is not expanded, due to portability issues.


Regards,

-- 
Nicolas Goaziou

Re: [O] org.texi edits, patch attached

[Lambda Coder]

On Mon, Nov 14, 2016 at 11:47 PM, Nicolas Goaziou 
wrote:

> Could you send an updated patch?
>
> Nicolas Goaziou
>

Yes, see attached patch 2.

--Lambda Coder.


0002-doc-org.texi-Editorial-revisions-to-the-manual.patch.gz
Description: GNU Zip compressed data

Re: [O] org.texi edits, patch attached

[Nicolas Goaziou]

Hello,

Lambda Coder  writes:

> I've attached an updated patch file to this msg.

Thank you. Some comments and suggestions follow.

> -Source code can be included in Org mode documents using a @samp{src} block,
> -e.g.:
> +Source code here refers to any code typed in Org mode documents.  Org can
> +manage source code in any Org file once such code is tagged with begin and
> +end markers.  Working with source code begins with tagging source code
> +blocks.  Such source code blocks can be put anywhere in an Org document.

I don't think we should add this last sentence, which may be misleading.
E.g., you cannot put a source block in a comment or a fixed width
area...

> +An important feature of Org's execution of the @samp{src} code blocks is
> +passing variables, functions, and results between @samp{src} blocks.  Such
> +interoperability uses a common syntax even if these @samp{src} blocks are in
> +different source code languages.  The integration extends to linking the
> +debugger's error messages to the line in the source code block in the Org
> +file.  That should partly explain why this functionality by the original
> +contributors, Eric Schulte and Dan Davison, was called
> @samp{Org-babel}.

@samp{Org Babel}.

> +Org mode's @ref{Easy templates} system speeds up creating @samp{src} blocks
> +with just a couple of keystrokes.  Don't be put-off by having to type or
> +remember the source block syntax.  Emacs already has other completion systems
> +(yasnippet and company, to name two) that can be configured to create these

I don't think we should name them since they are not built-in.

> +Optional.  Heading arguments control many aspects of evaluation, export and
> +tangling of code blocks (see @ref{Header arguments}).  Using Org's properties

  (@pxref{Header arguments})

> +Extracting source code from code blocks is one of the basic tasks in literate
> +programming.  Org's features makes it an ideal tool for creating literate
> +programming documents.  In literate programming parlance, on creation, such
> +documents are @emph{woven} with code and documentation, and on export, the
> +code is @emph{tangled} for execution by a computer.  Org export facilitates
> +weaving and tangling with several customization options.

ITYM "Org babel" not "Org export".

> +When Org tangles the source code blocks, it expands, merges, and transforms
> +source code blocks.  Then it recomposes them into one or more separate files
> +(as specified in the options).  During this tangling process, Org expands
> +variables in the source code, and also resolve any ``noweb'' style references
> +(see @ref{Noweb reference syntax}).

  (@pxref{Noweb reference syntax})

> +Debuggers normally link errors and messages back to the source code.  But for
> +tangled files, we want to link back to the Org file, not to the tangled
> +source file.  To make this extra jump, Org uses
> +@code{org-babel-tangle-jump-to-org} function with two additional source code
> +block header arguments: One, set @code{padline} (@ref{padline}) to true (the

  (@pxref{padline})

> +default setting).  Two, set @code{comments} (@ref{comments}) to
> @code{link}

Ditto.

> +After evaluation of the source code block, Org inserts the results after
> +inserting the label @code{#+RESULTS} in the Org file. Edit
> +@code{org-babel-results-keyword} to change the label, @code{#+RESULTS}.  The
> +results may optionally have a cache identifier and a block name.

I would remove the sentence starting with "Edit @code{...}". Results
keyword is always "results". The variable above is just a way to change
case. For this reason, I don't think it is worth documenting.

Also, a space is missing before "Edit"

> +By default, (@code{emacs-lisp} is enabled for evaluation.  The option to
> +enable additional languages for evaluation is
> +@code{org-babel-load-languages}.  Use the Emacs customization interface to
> +change. Or add code to the init file as shown here:

Missing space above.

> +For buffer-wide header arguments, use @code{#+PROPERTY:} lines anywhere in
> +the Org mode file (see @ref{Property syntax}).

  (@pxref{Property syntax})

> +The following example sets @code{*R*} (only for R code blocks) to

---only for @samp{R} code blocks---to

> +@code{session}, which means all R code is executed in the same session.  It
> +also sets @code{results} from all blocks to @code{silent}, which means
> +results of executions for all blocks (not just R code blocks) are ignored

---not just @samp{R} code blocks---are ignored

> +(therefore, not inserted in the buffer).

and, therefore, not inserted in the buffer.

> +Header arguments set through property drawers (see @ref{Property
> syntax})

(@pxref{Property syntax})

> +apply at the sub-tree level on down.  Since these property drawers can appear
> +anywhere in the file hierarchy, Org uses outermost call or source block to
> +resolve the values.  Org ignores @code{org-use-property-inheritance} setting.
> +
>  

Re: [O] org.texi edits, patch attached

[Lambda Coder]

On Fri, Nov 11, 2016 at 2:18 AM, Nicolas Goaziou 
wrote:

>
> If your FSF papers are in order, could you send an updated patch?
>
>
> Regards,
>
> --
> Nicolas Goaziou
>

I've attached an updated patch file to this msg.

--Lambda Coder.


0001-doc-org.texi-Editorial-revisions-to-the-manual.patch.gz
Description: GNU Zip compressed data

Re: [O] org.texi edits, patch attached

[Bastien Guerry]

Hi,

Nicolas Goaziou  writes:

> Have you signed FSF papers already? You need to so that we can apply
> your non-trivial changes to documentation.

Yes, Lambda Coder has signed the FSF papers for both Emacs and Tramp.

> You also need to provide a proper commit message, listing sections
> modified in the manual. See commit message in the repo for examples.

Yes, see http://orgmode.org/worg/org-contribute.html#org4682cef for
details on how to write commit messages.

Thanks for the patches!

-- 
 Bastien

Re: [O] org.texi edits, patch attached

[Nicolas Goaziou]

Hello,

Lambda Coder  writes:

> Attached is a patch submission for org.texi file. Sorry for the large size
> of the attachment. I am posting to this list on Bastien's suggestion.
>
> The edits mainly pertain to org-babel, which is where most of my time is
> spent these days. This patch is an attempt to make the documentation more
> consistent with the rest of gnu manuals. Comments and suggestions
> welcome.

Thank you for the patch!

I didn't read through the whole set of changes but I'll make some
initial comments.

Have you signed FSF papers already? You need to so that we can apply
your non-trivial changes to documentation.

Also, Texinfo document requires two spaces after a full stop. There are
a couple of places in your changes that do not follow this.

You also need to provide a proper commit message, listing sections
modified in the manual. See commit message in the repo for examples.

If your FSF papers are in order, could you send an updated patch?


Regards,

-- 
Nicolas Goaziou

[O] org.texi edits, patch attached

[Lambda Coder]

Attached is a patch submission for org.texi file. Sorry for the large size
of the attachment. I am posting to this list on Bastien's suggestion.

The edits mainly pertain to org-babel, which is where most of my time is
spent these days. This patch is an attempt to make the documentation more
consistent with the rest of gnu manuals. Comments and suggestions welcome.

--sjlam...@gmail.com


0001-Documentation-edits.patch.gz
Description: GNU Zip compressed data