Re: Re: org-babel: Bugs with inline src_* blocks

["Eric Schulte" <schulte.eric@gmail.com>]

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
>>