Re: [PATCH] doc/org-manual.org: Extend table formulas Lisp form documentation

[Kyle Meyer]

Daniele Nicolodi writes:

> Hello,
>
> I always found the description of Lisp forms in Org table formulas not
> extremely clear, especially in regard to the use of mode flags. The
> attached patch tries to clarify the manual a bit.

Thanks.

> Would it be worth to mention org-sbe in the same section of the manual?

Yeah, it looks like there's no mention of org-sbe in the manual, so I
think so (as a separate patch).

> Subject: [PATCH] doc/org-manual.org: Extend table formulas Lisp form
>  documentation
>
> Be more explicit about how fields are interpolated into the Lisp
> forms, clarify the use of mode flags, and add a cuple more examples.

s/cuple/couple/

Typically a manual change will get a "* doc/org-manual.org (<section>):"
entry in the commit message.

> ---
>  doc/org-manual.org | 60 +++++++++++++++++++++++++++-------------------
>  1 file changed, 36 insertions(+), 24 deletions(-)
[...]
> +By default, references are interpolated as literal Lisp strings: the
> +field content is replaced in the Lisp form stripped of leading and
> +trailing white space and surrounded in double-quotes.  For example:
>  
> -Here are a few examples---note how the =N= mode is used when we do
> -computations in Lisp:
> +: '(concat $1 $2)
>  
> -- ='(concat (substring $1 1 2) (substring $1 0 1) (substring $1 2))= ::
> +concatenates the content of columns 1 and column 2.

This and similar spots in this patch produce incorrect indentation in
the info output:

  trailing white space and surrounded in double-quotes.  For example:
  
       '(concat $1 $2)
  
     concatenates the content of columns 1 and column 2.

Adding "#+texinfo: @noindent" above the line would prevent that.  To
check the result, you can generate the info output with `make info' and
then visit it with `C-u C-h i doc/org'.

Aside from that, the changes here look like an improvement to me.  As
far as "interpolated" goes, this patch adds one more instance to a
section that carries 4 of the 5 occurrences in the code base, so I'd say
it's fine to leave as is.  I think the "replaced" or "substituted"
suggestions by Tim Cross are good ones, though, if anyone cares to send
a follow-up patch.