* export of src block ignores :results
@ 2016-09-29 6:43 Thomas Alexander Gerds
0 siblings, 0 replies; 12+ messages in thread
From: Thomas Alexander Gerds @ 2016-09-29 6:43 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* export of src block ignores :results
@ 2016-09-29 6:42 Thomas Alexander Gerds
2016-09-29 16:25 ` Charles C. Berry
0 siblings, 1 reply; 12+ messages in thread
From: Thomas Alexander Gerds @ 2016-09-29 6:42 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: export of src block ignores :results
2016-09-29 6:42 Thomas Alexander Gerds
@ 2016-09-29 16:25 ` Charles C. Berry
2016-09-29 19:53 ` Thomas Alexander Gerds
0 siblings, 1 reply; 12+ messages in thread
From: Charles C. Berry @ 2016-09-29 16:25 UTC (permalink / raw)
To: Thomas Alexander Gerds; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: export of src block ignores :results
2016-09-29 16:25 ` Charles C. Berry
@ 2016-09-29 19:53 ` Thomas Alexander Gerds
2016-09-29 21:02 ` Charles C. Berry
0 siblings, 1 reply; 12+ messages in thread
From: Thomas Alexander Gerds @ 2016-09-29 19:53 UTC (permalink / raw)
To: Charles C. Berry; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: export of src block ignores :results
2016-09-29 19:53 ` Thomas Alexander Gerds
@ 2016-09-29 21:02 ` Charles C. Berry
2016-09-30 3:39 ` Charles C. Berry
0 siblings, 1 reply; 12+ messages in thread
From: Charles C. Berry @ 2016-09-29 21:02 UTC (permalink / raw)
To: Thomas Alexander Gerds; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: export of src block ignores :results
2016-09-29 21:02 ` Charles C. Berry
@ 2016-09-30 3:39 ` Charles C. Berry
2016-09-30 5:06 ` Thomas Alexander Gerds
2016-10-01 8:37 ` Nicolas Goaziou
0 siblings, 2 replies; 12+ messages in thread
From: Charles C. Berry @ 2016-09-30 3:39 UTC (permalink / raw)
To: Thomas Alexander Gerds; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: export of src block ignores :results
2016-09-30 3:39 ` Charles C. Berry
@ 2016-09-30 5:06 ` Thomas Alexander Gerds
2016-09-30 17:05 ` Charles C. Berry
2016-10-01 8:37 ` Nicolas Goaziou
1 sibling, 1 reply; 12+ messages in thread
From: Thomas Alexander Gerds @ 2016-09-30 5:06 UTC (permalink / raw)
To: Charles C. Berry; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: export of src block ignores :results
2016-09-30 5:06 ` Thomas Alexander Gerds
@ 2016-09-30 17:05 ` Charles C. Berry
2016-10-01 5:46 ` Thomas Alexander Gerds
0 siblings, 1 reply; 12+ messages in thread
From: Charles C. Berry @ 2016-09-30 17:05 UTC (permalink / raw)
To: Thomas Alexander Gerds; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: export of src block ignores :results
2016-09-30 17:05 ` Charles C. Berry
@ 2016-10-01 5:46 ` Thomas Alexander Gerds
2016-10-01 16:32 ` Charles C. Berry
0 siblings, 1 reply; 12+ messages in thread
From: Thomas Alexander Gerds @ 2016-10-01 5:46 UTC (permalink / raw)
To: Charles C. Berry; +Cc: emacs-orgmode, istazahn
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: export of src block ignores :results
2016-10-01 5:46 ` Thomas Alexander Gerds
@ 2016-10-01 16:32 ` Charles C. Berry
2016-10-02 11:08 ` Thomas Alexander Gerds
0 siblings, 1 reply; 12+ messages in thread
From: Charles C. Berry @ 2016-10-01 16:32 UTC (permalink / raw)
To: Thomas Alexander Gerds; +Cc: emacs-orgmode, istazahn
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: export of src block ignores :results
2016-10-01 16:32 ` Charles C. Berry
@ 2016-10-02 11:08 ` Thomas Alexander Gerds
0 siblings, 0 replies; 12+ messages in thread
From: Thomas Alexander Gerds @ 2016-10-02 11:08 UTC (permalink / raw)
To: Charles C. Berry; +Cc: emacs-orgmode, istazahn
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: export of src block ignores :results
2016-09-30 3:39 ` Charles C. Berry
2016-09-30 5:06 ` Thomas Alexander Gerds
@ 2016-10-01 8:37 ` Nicolas Goaziou
1 sibling, 0 replies; 12+ messages in thread
From: Nicolas Goaziou @ 2016-10-01 8:37 UTC (permalink / raw)
To: Charles C. Berry; +Cc: emacs-orgmode, Thomas Alexander Gerds
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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2016-10-02 11:08 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-09-29 6:43 export of src block ignores :results Thomas Alexander Gerds
-- strict thread matches above, loose matches on Subject: below --
2016-09-29 6:42 Thomas Alexander Gerds
2016-09-29 16:25 ` Charles C. Berry
2016-09-29 19:53 ` Thomas Alexander Gerds
2016-09-29 21:02 ` Charles C. Berry
2016-09-30 3:39 ` Charles C. Berry
2016-09-30 5:06 ` Thomas Alexander Gerds
2016-09-30 17:05 ` Charles C. Berry
2016-10-01 5:46 ` Thomas Alexander Gerds
2016-10-01 16:32 ` Charles C. Berry
2016-10-02 11:08 ` Thomas Alexander Gerds
2016-10-01 8:37 ` Nicolas Goaziou
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).