* org-babel: Bugs with inline src_* blocks
@ 2011-02-15 2:31 Paul Sexton
2011-02-15 6:10 ` Suvayu Ali
2011-02-15 18:42 ` Eric Schulte
0 siblings, 2 replies; 6+ messages in thread
From: Paul Sexton @ 2011-02-15 2:31 UTC (permalink / raw)
To: emacs-orgmode
I am experiencing a couple of significant bugs with inline src blocks in
org-babel -- ie blocks of the form src_LANG{EXPRESSION}. I am using the
development version of org, checked out a few days ago.
Pressing C-c C-c with the cursor on such a block is supposed to evaluate it and
echo the result to the minibuffer. However in recent versions of org (the last
3 months or so) this behaviour has become broken, at least for me.
The following is an example file.
------start-------
#+BABEL: :session s1 :exports value latex :results raw
#+BEGIN_SRC R :results none :exports none
1+2+3
#+END_SRC
src_R{1+1}
------end--------
Pressing C-c C-c with the cursor on the inline block produces the error:
'R' is not recognized as an internal or external command,
operable program or batch file.
This happens even if the session named s1 is already running. However, if I
first evaluate the BEGIN_SRC ... END_SRC block, using
org-babel-execute-src-block, and then reattempt to evaluate the inline block, it
will work. If I then press C-c C-c on the '#+BABEL:' line at the start of the
file, the inline block goes back to producing the error.
The second, and more aggravating, error is do with the consequences of
evaluating inline blocks. Formerly the result would be echoed in the
minibuffer, and the document itself would not be altered. Now org has taken to
inserting the result after the block, the same behaviour as a non-inline block.
The header arguments used for this insertion seem to carry over either from the
previous non-inline block, or possibly the global settings (BABEL: line).
So for example, if I press C-c C-c on the src_R{1+1} above, I get:
-------
src_R{1+1} #+BEGIN_LaTeX
2#+END_LaTeX
-------
I want inline code blocks to replace themselves with their result when
exporting the document to latex etc. I *never* want them to paste their results
into the document while editing - that is what non-inline blocks are for.
Is this change in behaviour intentional? If so is there a setting that will
revert to the old behaviour?
Paul
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: org-babel: Bugs with inline src_* blocks
2011-02-15 2:31 org-babel: Bugs with inline src_* blocks Paul Sexton
@ 2011-02-15 6:10 ` Suvayu Ali
2011-02-15 18:42 ` Eric Schulte
1 sibling, 0 replies; 6+ messages in thread
From: Suvayu Ali @ 2011-02-15 6:10 UTC (permalink / raw)
To: emacs-orgmode
Hi Paul,
On Tue, 15 Feb 2011 02:31:27 +0000 (UTC)
Paul Sexton <psexton@xnet.co.nz> wrote:
> Is this change in behaviour intentional? If so is there a setting
> that will revert to the old behaviour?
>
I don't know the answer to your question however my question would be
how up to date is your org-mode install? I remember there was a bugfix
for a problem similar to this very recently (sometime in the last 2
weeks). Maybe all you are missing is a =git pull=?
> Paul
GL
--
Suvayu
Open source is the future. It sets us free.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: org-babel: Bugs with inline src_* blocks
2011-02-15 2:31 org-babel: Bugs with inline src_* blocks Paul Sexton
2011-02-15 6:10 ` Suvayu Ali
@ 2011-02-15 18:42 ` Eric Schulte
2011-02-15 21:22 ` Paul Sexton
1 sibling, 1 reply; 6+ messages in thread
From: Eric Schulte @ 2011-02-15 18:42 UTC (permalink / raw)
To: Paul Sexton; +Cc: emacs-orgmode
Paul Sexton <psexton@xnet.co.nz> writes:
> I am experiencing a couple of significant bugs with inline src blocks in
> org-babel -- ie blocks of the form src_LANG{EXPRESSION}. I am using the
> development version of org, checked out a few days ago.
>
> Pressing C-c C-c with the cursor on such a block is supposed to evaluate it and
> echo the result to the minibuffer. However in recent versions of org (the last
> 3 months or so) this behaviour has become broken, at least for me.
>
> The following is an example file.
>
> ------start-------
> #+BABEL: :session s1 :exports value latex :results raw
>
> #+BEGIN_SRC R :results none :exports none
> 1+2+3
> #+END_SRC
>
>
> src_R{1+1}
> ------end--------
>
> Pressing C-c C-c with the cursor on the inline block produces the error:
>
> 'R' is not recognized as an internal or external command,
> operable program or batch file.
>
> This happens even if the session named s1 is already running. However, if I
> first evaluate the BEGIN_SRC ... END_SRC block, using
> org-babel-execute-src-block, and then reattempt to evaluate the inline block, it
> will work. If I then press C-c C-c on the '#+BABEL:' line at the start of the
> file, the inline block goes back to producing the error.
>
I just tried your example from above, and I can not reproduce this
error. Maybe as Suvayu suggested you should try grabbing the latest
version of Org-mode and see if that fixes this issue.
>
> The second, and more aggravating, error is do with the consequences of
> evaluating inline blocks. Formerly the result would be echoed in the
> minibuffer, and the document itself would not be altered. Now org has taken to
> inserting the result after the block, the same behaviour as a non-inline block.
> The header arguments used for this insertion seem to carry over either from the
> previous non-inline block, or possibly the global settings (BABEL: line).
>
> So for example, if I press C-c C-c on the src_R{1+1} above, I get:
>
> -------
> src_R{1+1} #+BEGIN_LaTeX
> 2#+END_LaTeX
>
> -------
>
> I want inline code blocks to replace themselves with their result when
> exporting the document to latex etc. I *never* want them to paste their results
> into the document while editing - that is what non-inline blocks are for.
>
Hi, I agree with your intuition here, but I changed the default inline
header argument so that others would be able to use inline code blocks
and have the results inserted. To regain the behavior you describe,
simply adjust the value of `org-babel-default-inline-header-args' as
follows in your .emacs file.
#+begin_src emacs-lisp
(setf org-babel-default-inline-header-args
'((:session . "none")
(:results . "silent")
(:exports . "results")))
#+end_src
Best -- Eric
>
> Is this change in behaviour intentional? If so is there a setting that will
> revert to the old behaviour?
>
> Paul
>
>
>
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: org-babel: Bugs with inline src_* blocks
2011-02-15 18:42 ` Eric Schulte
@ 2011-02-15 21:22 ` Paul Sexton
2011-02-15 23:36 ` Dan Davison
0 siblings, 1 reply; 6+ messages in thread
From: Paul Sexton @ 2011-02-15 21:22 UTC (permalink / raw)
To: emacs-orgmode
Eric Schulte <schulte.eric <at> gmail.com> writes:
> Hi, I agree with your intuition here, but I changed the default inline
> header argument so that others would be able to use inline code blocks
> and have the results inserted. To regain the behavior you describe,
> simply adjust the value of `org-babel-default-inline-header-args' as
> follows in your .emacs file.
>
> #+begin_src emacs-lisp
> (setf org-babel-default-inline-header-args
> '((:session . "none")
> (:results . "silent")
> (:exports . "results")))
> #+end_src
Thanks Eric. The 'default' behaviour I experienced where inline blocks
were inheriting behaviour from elsewhere seems odd however. Is it intended
to work this way?
Paul
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: org-babel: Bugs with inline src_* blocks
2011-02-15 21:22 ` Paul Sexton
@ 2011-02-15 23:36 ` Dan Davison
2011-02-20 9:20 ` Eric Schulte
0 siblings, 1 reply; 6+ messages in thread
From: Dan Davison @ 2011-02-15 23:36 UTC (permalink / raw)
To: Paul Sexton; +Cc: emacs-orgmode
Paul Sexton <psexton@xnet.co.nz> writes:
> Eric Schulte <schulte.eric <at> gmail.com> writes:
>> Hi, I agree with your intuition here, but I changed the default inline
>> header argument so that others would be able to use inline code blocks
>> and have the results inserted. To regain the behavior you describe,
>> simply adjust the value of `org-babel-default-inline-header-args' as
>> follows in your .emacs file.
>>
>> #+begin_src emacs-lisp
>> (setf org-babel-default-inline-header-args
>> '((:session . "none")
>> (:results . "silent")
>> (:exports . "results")))
>> #+end_src
>
> Thanks Eric. The 'default' behaviour I experienced where inline blocks
> were inheriting behaviour from elsewhere seems odd however.
Hi Paul, Eric,
Paul -- I do agree with you. I've had to manually delete unwanted inline
src output a few times in the last few days.
I think we did have the behaviour we want before -- replacement during
export but no modification of the buffer in interactive use. Could we
make the default behave so that it does "replace" during export and
"silent" during normal interactive evaluation? (Or some similar change
to ob-exp.el?)
Dan
> Is it intended
> to work this way?
>
> Paul
>
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Re: org-babel: Bugs with inline src_* blocks
2011-02-15 23:36 ` Dan Davison
@ 2011-02-20 9:20 ` Eric Schulte
0 siblings, 0 replies; 6+ messages in thread
From: Eric Schulte @ 2011-02-20 9:20 UTC (permalink / raw)
To: Dan Davison; +Cc: emacs-orgmode, Paul Sexton
Dan Davison <dandavison7@gmail.com> writes:
> Paul Sexton <psexton@xnet.co.nz> writes:
>
>> Eric Schulte <schulte.eric <at> gmail.com> writes:
>>> Hi, I agree with your intuition here, but I changed the default inline
>>> header argument so that others would be able to use inline code blocks
>>> and have the results inserted. To regain the behavior you describe,
>>> simply adjust the value of `org-babel-default-inline-header-args' as
>>> follows in your .emacs file.
>>>
>>> #+begin_src emacs-lisp
>>> (setf org-babel-default-inline-header-args
>>> '((:session . "none")
>>> (:results . "silent")
>>> (:exports . "results")))
>>> #+end_src
>>
>> Thanks Eric. The 'default' behaviour I experienced where inline blocks
>> were inheriting behaviour from elsewhere seems odd however.
>
> Hi Paul, Eric,
>
> Paul -- I do agree with you. I've had to manually delete unwanted inline
> src output a few times in the last few days.
>
> I think we did have the behaviour we want before -- replacement during
> export but no modification of the buffer in interactive use. Could we
> make the default behave so that it does "replace" during export and
> "silent" during normal interactive evaluation? (Or some similar change
> to ob-exp.el?)
>
The easiest way to have header argument values vary between interactive
and export evaluation is to place raw elisp in the header argument
value. The following (after pulling the latest version of Org-mode)
results in the behavior you describe.
#+begin_src emacs-lisp :results silent
(setf org-babel-default-inline-header-args
'((:session . "none")
(:results . (if (boundp 'org-current-export-file) "replace" "silent"))
(:exports . "results")))
#+end_src
I think this is generally the most desirable behavior, and I'd vote that
this become the default header argument value for inline code blocks.
Best -- Eric
>
> Dan
>
>
>> Is it intended
>> to work this way?
>>
>> Paul
>>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-02-20 9:24 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-02-15 2:31 org-babel: Bugs with inline src_* blocks Paul Sexton
2011-02-15 6:10 ` Suvayu Ali
2011-02-15 18:42 ` Eric Schulte
2011-02-15 21:22 ` Paul Sexton
2011-02-15 23:36 ` Dan Davison
2011-02-20 9:20 ` Eric Schulte
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).