emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Paul Sexton <psexton@xnet.co.nz>
To: emacs-orgmode@gnu.org
Subject: org-babel: Bugs with inline src_* blocks
Date: Tue, 15 Feb 2011 02:31:27 +0000 (UTC)	[thread overview]
Message-ID: <loom.20110215T031505-810@post.gmane.org> (raw)

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

             reply	other threads:[~2011-02-15  2:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-15  2:31 Paul Sexton [this message]
2011-02-15  6:10 ` org-babel: Bugs with inline src_* blocks 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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=loom.20110215T031505-810@post.gmane.org \
    --to=psexton@xnet.co.nz \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).