export of src block ignores :results

export of src block ignores :results

[Thomas Alexander Gerds]

Hi

org's development version (I am using the one updated yesterday: 2b22d50
Nicolas Go 2016-09-28) seems to ignore the :results setting of a src
block. more specifically, the export of this

#+BEGIN_SRC R  :results output :exports code  :session *R* :cache yes 
2+2
#+END_SRC

#+RESULTS[<2016-09-29 08:32:48> e8e7ff579309fc6cacb1e75a0c1c671366c2eaf8]:
: [1] 4

should *not* include the results, but it does.  the elpa version, e.g.,
org-20160509, respects the :results setting. I tried to debug, but could
not find the place in the process where the option :results is
interpreted. here is how far I got: in the development version the
result of the function org-element-parse-buffer does include the result
of the src block "4" whereas in the elpa version result of the function
org-element-parse-buffer does include it.

did I miss something or is this a bug?

thanks, 
Thomas

-- 
sent from nil

export of src block ignores :results

[Thomas Alexander Gerds]

Hi

org's development version (I am using the one updated yesterday: 2b22d50
Nicolas Go 2016-09-28) seems to ignore the :results setting of a src
block. more specifically, the export of this

#+BEGIN_SRC R  :results output :exports code  :session *R* :cache yes 
2+2
#+END_SRC

#+RESULTS[<2016-09-29 08:32:48> e8e7ff579309fc6cacb1e75a0c1c671366c2eaf8]:
: [1] 4

should *not* include the results, but it does.  the elpa version, e.g.,
org-20160509, respects the :results setting. I tried to debug, but could
not find the place in the process where the option :results is
interpreted. here is how far I got: in the development version the
result of the function org-element-parse-buffer does include the result
of the src block "4" whereas in the elpa version result of the function
org-element-parse-buffer does include it.

did I miss something or is this a bug?

thanks, 
Thomas

-- 
sent from nil

Re: export of src block ignores :results

[Charles C. Berry]

On Thu, 29 Sep 2016, Thomas Alexander Gerds wrote:

> Hi
>
> org's development version (I am using the one updated yesterday: 2b22d50
> Nicolas Go 2016-09-28) seems to ignore the :results setting of a src
> block. more specifically, the export of this
>
> #+BEGIN_SRC R  :results output :exports code  :session *R* :cache yes
> 2+2
> #+END_SRC
>
> #+RESULTS[<2016-09-29 08:32:48> e8e7ff579309fc6cacb1e75a0c1c671366c2eaf8]:
> : [1] 4
>
> should *not* include the results, but it does.

Using latest (release_8.3.6-1178-g2b22d5), I cannot reproduce.

Does `org-babel-sha1-hash' (C-c C-v a with point in the src block)
really yield "<2016-09-29 08:32:48> e8e7ff..." ??

I get "e8e7ff..." which causes no problems.

HTH,

Chuck

Re: export of src block ignores :results

[Thomas Alexander Gerds]

Hi Chuck

thanks for checking. my org-version is the same
release_8.3.6-1178-g2b22d5

to get the date and time of the in the results:

(setq org-babel-hash-show-time t)

but even without this option the results of the block are exported no
matter what. could someone point to the place in the export process
where the :results option is interpreted?

Thomas

"Charles C. Berry" <ccberry@ucsd.edu> writes:

> On Thu, 29 Sep 2016, Thomas Alexander Gerds wrote:
>
>> Hi
>> org's development version (I am using the one updated yesterday:
>> 2b22d50 Nicolas Go 2016-09-28) seems to ignore the :results setting
>> of a src block. more specifically, the export of this
>> #+BEGIN_SRC R :results output :exports code :session *R* :cache yes
>> 2+2 #+END_SRC
>> #+RESULTS[<2016-09-29 08:32:48>
>> e8e7ff579309fc6cacb1e75a0c1c671366c2eaf8]: : [1] 4
>> should *not* include the results, but it does.
>
> Using latest (release_8.3.6-1178-g2b22d5), I cannot reproduce.
>
> Does `org-babel-sha1-hash' (C-c C-v a with point in the src block)
> really yield "<2016-09-29 08:32:48> e8e7ff..." ??
>
> I get "e8e7ff..." which causes no problems.
>
> HTH,
>
> Chuck
>
>

-- 
Thomas A. Gerds -- Department of Biostatistics Copenhagen
University of Copenhagen, Oester Farimagsgade 5, 1014 Copenhagen,
Denmark

Re: export of src block ignores :results

[Charles C. Berry]

On Thu, 29 Sep 2016, Thomas Alexander Gerds wrote:

> Hi Chuck
>
> thanks for checking. my org-version is the same
> release_8.3.6-1178-g2b22d5
>
> to get the date and time of the in the results:
>
> (setq org-babel-hash-show-time t)
>
> but even without this option the results of the block are exported no
> matter what. could someone point to the place in the export process
> where the :results option is interpreted?

You probably want `org-babel-current-result-hash', which AFAICS does not 
recognize the `show-time' variant.

I think you'll need some regexp magic to make it work.

Chuck

Re: export of src block ignores :results

[Charles C. Berry]

On Thu, 29 Sep 2016, Charles C. Berry wrote:

> On Thu, 29 Sep 2016, Thomas Alexander Gerds wrote:
>
>> Hi Chuck
>> 
>> thanks for checking. my org-version is the same
>> release_8.3.6-1178-g2b22d5
>> 
>> to get the date and time of the in the results:
>> 
>> (setq org-babel-hash-show-time t)
>> 
>> but even without this option the results of the block are exported no
>> matter what. could someone point to the place in the export process
>> where the :results option is interpreted?
>
> You probably want `org-babel-current-result-hash', which AFAICS does not 
> recognize the `show-time' variant.
>
> I think you'll need some regexp magic to make it work.

You might try this:


#+BEGIN_SRC emacs-lisp
   (setq org-babel-result-regexp
 	(concat
 	 "^[ 	]*#\\+RESULTS\\[\\(?:<[0-9]"
 	 "\\{4\\}-[0-9]\\{2\\}-[0-9]\\{2\\} ?"
 	 "[0-2][0-9]:[0-6][0-9]:[0-6][0-9]> ?"
 	 "[^
\n[:alnum:]]*\\)?\\([[:alnum:]]+\\)"
 	 "\\]?:[	]*"))
#+END_SRC


The line wrap after "[^ is due to C-M (you type C-q C-M to insert it if 
your email client messes with it and you need to redo it)

This seems like an innocuous change, but I haven't yet run this thru `make 
test' so beware.


Chuck

Re: export of src block ignores :results

[Thomas Alexander Gerds]

thanks for looking into this. it would be great if the regexp could be
changed to catch the show-time variant. the regexp you sent in your
previous mail works for me, i.e., the result of
(progn (looking-at org-babel-result-regexp)(match-string 1))
is the same with and without the show-time option.

anyway, the original problem is not solved yet.
org-babel-current-result-hash is related to the execution of the src
block which is independent of the export process since I have

(setq org-export-babel-evaluate nil). 

and the problem that the results are exported in case of ":results code"
persists when I set (setq org-babel-hash-show-time nil)

so, unfortunately my question remains. which function in the export
process interprets the "results code" option?

Thomas

"Charles C. Berry" <ccberry@ucsd.edu> writes:

> On Thu, 29 Sep 2016, Charles C. Berry wrote:
> 
>> On Thu, 29 Sep 2016, Thomas Alexander Gerds wrote:
>>
>>> Hi Chuck
>>> 
>>> thanks for checking. my org-version is the same
>>> release_8.3.6-1178-g2b22d5
>>> 
>>> to get the date and time of the in the results:
>>> 
>>> (setq org-babel-hash-show-time t)
>>> 
>>> but even without this option the results of the block are exported
>>> no matter what. could someone point to the place in the export
>>> process where the :results option is interpreted?
>> You probably want `org-babel-current-result-hash', which AFAICS does
>> not recognize the `show-time' variant.
>> I think you'll need some regexp magic to make it work.
>
> You might try this:
>
> #+BEGIN_SRC emacs-lisp
>    (setq org-babel-result-regexp
>  	(concat
>  	 "^[ 	]*#\\+RESULTS\\[\\(?:<[0-9]"
>  	 "\\{4\\}-[0-9]\\{2\\}-[0-9]\\{2\\} ?"
>  	 "[0-2][0-9]:[0-6][0-9]:[0-6][0-9]> ?"
>  	 "[^
> \n[:alnum:]]*\\)?\\([[:alnum:]]+\\)"
>  	 "\\]?:[	]*"))
> #+END_SRC
>
> The line wrap after "[^ is due to C-M (you type C-q C-M to insert it
> if your email client messes with it and you need to redo it)
>
> This seems like an innocuous change, but I haven't yet run this thru
> `make test' so beware.
>
> Chuck
>
>

-- 
Thomas A. Gerds -- Department of Biostatistics Copenhagen
University of Copenhagen, Oester Farimagsgade 5, 1014 Copenhagen,
Denmark

Re: export of src block ignores :results

[Charles C. Berry]

On Thu, 29 Sep 2016, Thomas Alexander Gerds wrote:

>
[deleted]

>
> anyway, the original problem is not solved yet.
> org-babel-current-result-hash is related to the execution of the src
> block which is independent of the export process since I have
>
> (setq org-export-babel-evaluate nil).
>
> and the problem that the results are exported in case of ":results code"
> persists when I set (setq org-babel-hash-show-time nil)
>

Follow the advice in the docstring for `org-export-babel-evaluate'. Use 
`:eval never-export'. Set org-export-babel-evaluate to t.


> so, unfortunately my question remains. which function in the export
> process interprets the "results code" option?


With org-export-babel-evaluate set to nil, none of the babel functions 
are run. And none of the export transcoders take account of the header 
args, AFAICS. So the answer is `none of them'.

Chuck

Re: export of src block ignores :results

[Thomas Alexander Gerds]

right, this is what changed and setting :eval never-export on a each
block solves the problem. however, the new way breaks all my existing
org-code.

is there a reason why the header args have to be ignored when
org-export-babel-evaluate is nil? or asking more directly: would it be
possible to have another option, e.g.,

(setq org-export-babel-evaluate 'never-eval-obey-header-args)

such that the export process does never evaluate src code but header
arguments are always obeyed?

actually, my org-life improved alot when I found Ista Zahn's (cc) remark
in the org-mode mailing list about setting org-export-babel-evaluate to
nil. here is the quote:

,----Fri, 21 Aug 2015 Re: [O] "user-error: No language for src block ...
|                                                                        |
| Unless you've restored sanity by setting org-export-babel-evaluate to  |
| nil. Personally I think this is not a good default. Source block       |
| evaluation and export are distinct actions, and I don't see why they   |
| should be linked by default.                                           |
|                                                                        |
| https://lists.gnu.org/archive/html/emacs-orgmode/2015-08/msg00940.html |
`----

to me personally, the fact that one can separate the export process from
the source block evaluation in org-mode is one of the great advantages
over R-studio's markdown.

Thomas


"Charles C. Berry" <ccberry@ucsd.edu> writes:

> On Thu, 29 Sep 2016, Thomas Alexander Gerds wrote:
>
>>
> [deleted]
>
> Follow the advice in the docstring for
> `org-export-babel-evaluate'. Use `:eval never-export'. Set
> org-export-babel-evaluate to t.
>
> Chuck
>
>

-- 
sent from nil

Re: export of src block ignores :results

[Nicolas Goaziou]

Hello,

"Charles C. Berry" <ccberry@ucsd.edu> writes:

> You might try this:
>
> #+BEGIN_SRC emacs-lisp
>    (setq org-babel-result-regexp
>  	(concat
>  	 "^[ 	]*#\\+RESULTS\\[\\(?:<[0-9]"
>  	 "\\{4\\}-[0-9]\\{2\\}-[0-9]\\{2\\} ?"
>  	 "[0-2][0-9]:[0-6][0-9]:[0-6][0-9]> ?"
>  	 "[^
> \n[:alnum:]]*\\)?\\([[:alnum:]]+\\)"
>  	 "\\]?:[	]*"))
> #+END_SRC

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: export of src block ignores :results

[Charles C. Berry]

On Fri, 30 Sep 2016, Thomas Alexander Gerds wrote:

>
> right, this is what changed and setting :eval never-export on a each
> block solves the problem. however, the new way breaks all my existing
> org-code.

I don't follow this. What exactly is broken?

You know all the options for setting header args, right? System-wide, 
buffer-wide, etc. For buffer-wide setting, one line is all it takes:

: #+PROPERTY: header-args :eval never-export

(and remember to C-c C-c on that line whenever you insert/edit it)

>
> is there a reason why the header args have to be ignored when
> org-export-babel-evaluate is nil? or asking more directly: would it be
> possible to have another option, e.g.,
>
> (setq org-export-babel-evaluate 'never-eval-obey-header-args)
>

But that is what :eval never-export does.

> such that the export process does never evaluate src code but header
> arguments are always obeyed?
>

Possible, yes. But since it adds no new capability and makes the babel 
code more involved, there isn't the motivtion to do it.

Chuck

Re: export of src block ignores :results

[Thomas Alexander Gerds]

you are absolutely right: I did not know about system-wide header
args. the following system-wide setting in the devel version is
equivalent to my old setting:

(setq org-export-babel-evaluate t)
(add-to-list 'org-babel-default-header-args '(:eval . "never-export"))

thanks again for your help and patience!

Thomas


"Charles C. Berry" <ccberry@ucsd.edu> writes:

> On Fri, 30 Sep 2016, Thomas Alexander Gerds wrote:
>
>> right, this is what changed and setting :eval never-export on a each
>> block solves the problem. however, the new way breaks all my
>> existing org-code.
>
> I don't follow this. What exactly is broken?
>
> You know all the options for setting header args, right? System-wide,
> buffer-wide, etc. For buffer-wide setting, one line is all it takes:
>
> : #+PROPERTY: header-args :eval never-export
>
> (and remember to C-c C-c on that line whenever you insert/edit it)
>
>> is there a reason why the header args have to be ignored when
>> org-export-babel-evaluate is nil? or asking more directly: would it
>> be possible to have another option, e.g.,
>> (setq org-export-babel-evaluate 'never-eval-obey-header-args)
>>
>
> But that is what :eval never-export does.
>
>> such that the export process does never evaluate src code but header
>> arguments are always obeyed?
>>
>
> Possible, yes. But since it adds no new capability and makes the babel
> code more involved, there isn't the motivtion to do it.
>
> Chuck
>
>
>

-- 
Thomas A. Gerds -- Department of Biostatistics Copenhagen
University of Copenhagen, Oester Farimagsgade 5, 1014 Copenhagen,
Denmark