all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* call_*() is not working inside #+DATE
@ 2016-03-07  1:58 Rafael Laboissiere
  2016-03-12  7:57 ` [PATCH] " Rafael Laboissiere
  0 siblings, 1 reply; 11+ messages in thread
From: Rafael Laboissiere @ 2016-03-07  1:58 UTC (permalink / raw)
  To: emacs-orgmode

The following used to work for me in the past:

    #+NAME: date
    #+BEGIN_SRC sh :results silent :exports results :tangle no
    date
    #+END_SRC
    #+TITLE: Sample
    #+AUTHOR: Me
    #+DATE: call_date()

and I saw the output of the shell command "date" when exporting the file 
to LaTeX.  However does not work for the current HEAD of the Git 
repository.

Using git-bisect, I discovered that the culprit is commit 85ff663, i.e. 
my code above works for commit 85ff663^ but fails for commit 85ff663.

Commit 85ff663 was a pretty large commit and, besides that, the new code 
introduced by it was posteriorly changed, so it is hard to find where the 
bug comes from.  Could someone more acquainted with the code try to look 
at this bug, please?

Thanks,

Rafael Laboissière

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] call_*() is not working inside #+DATE
  2016-03-07  1:58 call_*() is not working inside #+DATE Rafael Laboissiere
@ 2016-03-12  7:57 ` Rafael Laboissiere
  2016-03-12  8:51   ` Eric S Fraga
  2016-03-14 16:43   ` Rafael Laboissiere
  0 siblings, 2 replies; 11+ messages in thread
From: Rafael Laboissiere @ 2016-03-12  7:57 UTC (permalink / raw)
  To: emacs-orgmode

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

* Rafael Laboissiere <rafael@laboissiere.net> [2016-03-07 02:58]:

> The following used to work for me in the past:
>
>   #+NAME: date
>   #+BEGIN_SRC sh :results silent :exports results :tangle no
>   date
>   #+END_SRC
>   #+TITLE: Sample
>   #+AUTHOR: Me
>   #+DATE: call_date()
>
> and I saw the output of the shell command "date" when exporting the 
> file to LaTeX.  However does not work for the current HEAD of the Git 
> repository.
>
> Using git-bisect, I discovered that the culprit is commit 85ff663, 
> i.e. my code above works for commit 85ff663^ but fails for commit 
> 85ff663.
>
> Commit 85ff663 was a pretty large commit and, besides that, the new 
> code introduced by it was posteriorly changed, so it is hard to find 
> where the bug comes from.  Could someone more acquainted with the code 
> try to look at this bug, please?

I investigated this issue further and discovered that the constructs 
call_<name>(args) and src_<lang>{code} are not evaluated at all when they 
appear in a keyword line (starting with "#+<keyword>:").  Org-babel 
behaves in this way probably on purpose.  At any rate, it would be better 
if the current behavior is documented somewhere.  This may be 
accomplished with the patch attached below.

Best,

Rafael Laboissière

P.S.: For those who are reading this message and are interested in a 
solution for my original problem, here is the way I am getting around it 
right now.  When exporting to LaTeX, I wanted to have, as the contents of 
the \date{} macro, the date and the hash of the last Git commit of the 
current checkout HEAD, to which my Org document belongs.  Here is how I 
am doing it now:

    #+TITLE: Sample
    #+AUTHOR: Me
    #+BEGIN_SRC sh :results silent :exports results :tangle no
    git show -s --date=short --format="%cd [%h]" HEAD > GitDateCommit.tex
    #+END_SRC
    #+DATE: \input{GitDateCommit}

[-- Attachment #2: 0001-Document-lack-of-evaluation-of-inline-code-blocks-in.patch --]
[-- Type: text/x-diff, Size: 2030 bytes --]

From fa47439f9897c4bab436ecf4c9f08fa686ff0231 Mon Sep 17 00:00:00 2001
From: Rafael Laboissiere <rafael@laboissiere.net>
Date: Fri, 11 Mar 2016 23:04:00 +0100
Subject: [PATCH] Document lack of evaluation of inline code blocks in keyword
 lines

doc/org.texi (Evaluating code blocks): Add footnote explaining that
inline code blocks are not evaluated inside keyword lines.
---
 doc/org.texi | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index e423df7..ce478f5 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -15030,13 +15030,16 @@ evaluation from the @kbd{C-c C-c} key binding.}.  This will call the
 its results into the Org mode buffer.
 
 @cindex #+CALL
-It is also possible to evaluate named code blocks from anywhere in an Org
-mode buffer or an Org mode table.  These named code blocks can be located in
-the current Org mode buffer or in the ``Library of Babel'' (@pxref{Library of
-Babel}).  Named code blocks can be evaluated with a separate @code{#+CALL:}
-line or inline within a block of text.  In both cases the result is wrapped
-according to the value of @code{org-babel-inline-result-wrap}, which by
-default is @code{"=%s="} for markup that produces verbatim text.
+It is also possible to evaluate named code blocks from
+anywhere@footnote{Actually, the constructs call_<name>() and src_<lang>@{@}
+are not evaluated when they appear in a keyword line (i.e. lines starting
+with @code{#+KEYWORD:}, @pxref{In-buffer settings}).}  in an Org mode buffer
+or an Org mode table.  These named code blocks can be located in the current
+Org mode buffer or in the ``Library of Babel'' (@pxref{Library of Babel}).
+Named code blocks can be evaluated with a separate @code{#+CALL:} line or
+inline within a block of text.  In both cases the result is wrapped according
+to the value of @code{org-babel-inline-result-wrap}, which by default is
+@code{"=%s="} for markup that produces verbatim text.
 
 The syntax of the @code{#+CALL:} line is
 
-- 
2.7.0


^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [PATCH] call_*() is not working inside #+DATE
  2016-03-12  7:57 ` [PATCH] " Rafael Laboissiere
@ 2016-03-12  8:51   ` Eric S Fraga
  2016-03-12  9:34     ` Rafael Laboissiere
  2016-03-14 16:43   ` Rafael Laboissiere
  1 sibling, 1 reply; 11+ messages in thread
From: Eric S Fraga @ 2016-03-12  8:51 UTC (permalink / raw)
  To: Rafael Laboissiere; +Cc: emacs-orgmode

On Saturday, 12 Mar 2016 at 08:57, Rafael Laboissiere wrote:
> P.S.: For those who are reading this message and are interested in a 
> solution for my original problem, here is the way I am getting around it 
> right now.

Thanks for this alternate solution.
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.91.1, Org release_8.3.4-626-gb62d55

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] call_*() is not working inside #+DATE
  2016-03-12  8:51   ` Eric S Fraga
@ 2016-03-12  9:34     ` Rafael Laboissiere
  2016-03-13 17:24       ` Nicolas Goaziou
  0 siblings, 1 reply; 11+ messages in thread
From: Rafael Laboissiere @ 2016-03-12  9:34 UTC (permalink / raw)
  To: emacs-orgmode

* Eric S Fraga <e.fraga@ucl.ac.uk> [2016-03-12 08:51]:

> On Saturday, 12 Mar 2016 at 08:57, Rafael Laboissiere wrote:
>> P.S.: For those who are reading this message and are interested in a
>> solution for my original problem, here is the way I am getting around it
>> right now.
>
> Thanks for this alternate solution.

You are welcome.

It would be much better if the following construct worked:

    #+DATE: src_sh{git show -s --date=short --format="%cd [%h]" HEAD}

Unfortunately, it does not.  This behavior (or misbehavior, I do not 
know) can be traced down to the org-element-context function.  Suppose 
that you have the following content in a org-mode buffer:

    #+DATE: src_sh{date}
    src_sh{date}

With the cursor just after the underscore in the #+DATE line, 
org-element-context returns:

    (keyword
     (:key "DATE" :value "src_sh{date}" :begin 1 :end 22 :post-blank 0 :post-affiliated 1 :parent nil))

On the other hand, with the cursor just after the underscore in the next 
line, org-element-context returns (as it should be):

    (inline-src-block
     (:language "sh" :value "date" :parameters nil :begin 22 :end  34 :post-blank 0
       :parent (paragraph (:begin 22 :end 35 :contents-begin 22 :contents-end 35 :post-blank 0
                           :post-affiliated 22 :parent nil))))

This is the reason why Org-babel does not evaluate the inline source 
block in the #+DATE line.

Best,

Rafael Laboissière

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] call_*() is not working inside #+DATE
  2016-03-12  9:34     ` Rafael Laboissiere
@ 2016-03-13 17:24       ` Nicolas Goaziou
  2016-03-13 17:41         ` Rafael Laboissiere
  0 siblings, 1 reply; 11+ messages in thread
From: Nicolas Goaziou @ 2016-03-13 17:24 UTC (permalink / raw)
  To: Rafael Laboissiere; +Cc: emacs-orgmode

Hello,

Rafael Laboissiere <rafael@laboissiere.net> writes:

> It would be much better if the following construct worked:
>
>     #+DATE: src_sh{git show -s --date=short --format="%cd [%h]" HEAD}
>
> Unfortunately, it does not.  This behavior (or misbehavior, I do not 
> know) can be traced down to the org-element-context function.  Suppose 
> that you have the following content in a org-mode buffer:
>
>     #+DATE: src_sh{date}
>     src_sh{date}
>
> With the cursor just after the underscore in the #+DATE line, 
> org-element-context returns:
>
>     (keyword
>      (:key "DATE" :value "src_sh{date}" :begin 1 :end 22 :post-blank 0 :post-affiliated 1 :parent nil))
>
> On the other hand, with the cursor just after the underscore in the next 
> line, org-element-context returns (as it should be):
>
>     (inline-src-block
>      (:language "sh" :value "date" :parameters nil :begin 22 :end  34 :post-blank 0
>        :parent (paragraph (:begin 22 :end 35 :contents-begin 22 :contents-end 35 :post-blank 0
>                            :post-affiliated 22 :parent nil))))
>
> This is the reason why Org-babel does not evaluate the inline source 
> block in the #+DATE line.

Values from keyword are not parsed. Org used to make an exception for an
arbitrary bunch of them (e.g., DATE, TITLE, etc.). Now it is up to the
export back-ends to decide what keyword is going to be parsed.

I can think of two ways to solve this:

  1. Only evaluate the Babel code during export. Upon exporting the
     document, parsed keywords are known, so
     `org-babel-exp-process-buffer' may try to find "hidden" Babel code
     and execute it.

     This would however introduce a discrepancy between
     org-babel-execute-buffer and the behaviour upon exporting.

  2. Sort parsed keywords from regular ones at the syntax level, much
     like we did for export blocks recently. I.e., every keyword is
     parsed expect those marked as verbatim. I don't have an idea bout
     the involved syntax.

     This would probably induce some backward incompatibility.

WDYT?


Regards,

-- 
Nicolas Goaziou

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] call_*() is not working inside #+DATE
  2016-03-13 17:24       ` Nicolas Goaziou
@ 2016-03-13 17:41         ` Rafael Laboissiere
  0 siblings, 0 replies; 11+ messages in thread
From: Rafael Laboissiere @ 2016-03-13 17:41 UTC (permalink / raw)
  To: emacs-orgmode

* Nicolas Goaziou <mail@nicolasgoaziou.fr> [2016-03-13 18:24]:

> Rafael Laboissiere <rafael@laboissiere.net> writes:
>
>> It would be much better if the following construct worked:
>>
>>     #+DATE: src_sh{git show -s --date=short --format="%cd [%h]" HEAD}
>>
>> Unfortunately, it does not.  This behavior (or misbehavior, I do not 
>> know) can be traced down to the org-element-context function.
>>
>> [snip]
>
> Values from keyword are not parsed. Org used to make an exception for an 
> arbitrary bunch of them (e.g., DATE, TITLE, etc.). Now it is up to the 
> export back-ends to decide what keyword is going to be parsed.
>
> I can think of two ways to solve this:
>
>  1. Only evaluate the Babel code during export. Upon exporting the
>     document, parsed keywords are known, so
>     `org-babel-exp-process-buffer' may try to find "hidden" Babel code
>     and execute it.
>
>     This would however introduce a discrepancy between
>     org-babel-execute-buffer and the behaviour upon exporting.
>
>  2. Sort parsed keywords from regular ones at the syntax level, much
>     like we did for export blocks recently. I.e., every keyword is
>     parsed expect those marked as verbatim. I don't have an idea bout
>     the involved syntax.
>
>     This would probably induce some backward incompatibility.
>
> WDYT?

Thanks for your proposal.

I would vote for solution #1.  The discrepancy between 
org-babel-execute-buffer and the behaviour upon exporting that you 
mention would not bother me.

Whatever solution is adopted (or if the current behavior is kept), the 
info documentation must be updated.  Do you agree with the patch that I 
proposed earlier in this thread?

Best,

Rafael

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] call_*() is not working inside #+DATE
  2016-03-12  7:57 ` [PATCH] " Rafael Laboissiere
  2016-03-12  8:51   ` Eric S Fraga
@ 2016-03-14 16:43   ` Rafael Laboissiere
  2016-03-14 19:41     ` Nicolas Goaziou
  1 sibling, 1 reply; 11+ messages in thread
From: Rafael Laboissiere @ 2016-03-14 16:43 UTC (permalink / raw)
  To: emacs-orgmode

* Rafael Laboissiere <rafael@laboissiere.net> [2016-03-12 08:57]:
>
> [snip]
>
> I investigated this issue further and discovered that the constructs 
> call_<name>(args) and src_<lang>{code} are not evaluated at all when 
> they appear in a keyword line (starting with "#+<keyword>:"). 
> Org-babel behaves in this way probably on purpose.  At any rate, it 
> would be better if the current behavior is documented somewhere.  This 
> may be accomplished with the patch attached below.

I went ahead and committed the patch.

Rafael Laboissière

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] call_*() is not working inside #+DATE
  2016-03-14 16:43   ` Rafael Laboissiere
@ 2016-03-14 19:41     ` Nicolas Goaziou
  2016-03-15 10:23       ` Rafael Laboissiere
  0 siblings, 1 reply; 11+ messages in thread
From: Nicolas Goaziou @ 2016-03-14 19:41 UTC (permalink / raw)
  To: Rafael Laboissiere; +Cc: emacs-orgmode

Hello,

Rafael Laboissiere <rafael@laboissiere.net> writes:

> * Rafael Laboissiere <rafael@laboissiere.net> [2016-03-12 08:57]:
>>
>> [snip]
>>
>> I investigated this issue further and discovered that the constructs
>> call_<name>(args) and src_<lang>{code} are not evaluated at all when
>> they appear in a keyword line (starting with "#+<keyword>:").
>> Org-babel behaves in this way probably on purpose.  At any rate, it
>> would be better if the current behavior is documented somewhere.
>> This may be accomplished with the patch attached below.
>
> I went ahead and committed the patch.

I think this is a bit premature, as we're still discussing how to fix
this issue, so this documentation patch is likely to be removed soon.

Moreover, I don't think the problem doesn't appear on maint branch,
where you applied your patch. So, at the very least, it should be
removed from there.


Regards,

-- 
Nicolas Goaziou

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] call_*() is not working inside #+DATE
  2016-03-14 19:41     ` Nicolas Goaziou
@ 2016-03-15 10:23       ` Rafael Laboissiere
  2016-03-15 18:50         ` Nicolas Goaziou
  0 siblings, 1 reply; 11+ messages in thread
From: Rafael Laboissiere @ 2016-03-15 10:23 UTC (permalink / raw)
  To: emacs-orgmode

* Nicolas Goaziou <mail@nicolasgoaziou.fr> [2016-03-14 20:41]:

> Rafael Laboissiere <rafael@laboissiere.net> writes:
>
>> * Rafael Laboissiere <rafael@laboissiere.net> [2016-03-12 08:57]:
>>>
>>> [snip]
>>>
>> I went ahead and committed the patch.
>
> I think this is a bit premature, as we're still discussing how to fix 
> this issue, so this documentation patch is likely to be removed soon.

Hopefully, a solution will be found soon and the documentation will be 
adjusted accordingly.  Notice that, in section "Evaluating code blocks", 
it is written "It is also possible to evaluate named code blocks from 
anywhere […]".

> Moreover, I don't think the problem doesn't appear on maint branch, 
> where you applied your patch. So, at the very least, it should be 
> removed from there.

The problem affects both master and maint, currently.

Rafael Laboissière

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] call_*() is not working inside #+DATE
  2016-03-15 10:23       ` Rafael Laboissiere
@ 2016-03-15 18:50         ` Nicolas Goaziou
  2016-03-15 20:58           ` Rafael Laboissiere
  0 siblings, 1 reply; 11+ messages in thread
From: Nicolas Goaziou @ 2016-03-15 18:50 UTC (permalink / raw)
  To: Rafael Laboissiere; +Cc: emacs-orgmode

Hello,

Rafael Laboissiere <rafael@laboissiere.net> writes:

> Hopefully, a solution will be found soon and the documentation will be
> adjusted accordingly.  Notice that, in section "Evaluating code
> blocks", it is written "It is also possible to evaluate named code
> blocks from anywhere […]".

The problem is that the documentation patch is (partly) wrong. From
maint, you can try calling `org-babel-execute-buffer' in the following
document

  #+DATE: src_emacs-lisp{(+ 1 1)}

It is possible to evaluate code snippets in keywords. It is not
possible, AFAIR, to evaluate them during export.

> The problem affects both master and maint, currently.

See above. I don't see the point of documenting a bug. It doesn't help
fixing it. Anyway, it's a minor issue. Let's not waste too much time on
this.


Regards,

-- 
Nicolas Goaziou

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] call_*() is not working inside #+DATE
  2016-03-15 18:50         ` Nicolas Goaziou
@ 2016-03-15 20:58           ` Rafael Laboissiere
  0 siblings, 0 replies; 11+ messages in thread
From: Rafael Laboissiere @ 2016-03-15 20:58 UTC (permalink / raw)
  To: emacs-orgmode

* Nicolas Goaziou <mail@nicolasgoaziou.fr> [2016-03-15 19:50]:

> The problem is that the documentation patch is (partly) wrong. From 
> maint, you can try calling `org-babel-execute-buffer' in the following 
> document
>
>  #+DATE: src_emacs-lisp{(+ 1 1)}
>
> It is possible to evaluate code snippets in keywords.

It is strange, the inline source code block above is not evaluated for me 
from maint [commit 3e79c60] when calling `org-babel-execute-buffer'.

Rafael

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2016-03-15 20:58 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-03-07  1:58 call_*() is not working inside #+DATE Rafael Laboissiere
2016-03-12  7:57 ` [PATCH] " Rafael Laboissiere
2016-03-12  8:51   ` Eric S Fraga
2016-03-12  9:34     ` Rafael Laboissiere
2016-03-13 17:24       ` Nicolas Goaziou
2016-03-13 17:41         ` Rafael Laboissiere
2016-03-14 16:43   ` Rafael Laboissiere
2016-03-14 19:41     ` Nicolas Goaziou
2016-03-15 10:23       ` Rafael Laboissiere
2016-03-15 18:50         ` Nicolas Goaziou
2016-03-15 20:58           ` Rafael Laboissiere

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.