Maybe use `org-babel-default-inline-header-args'.
On Thu, Nov 13, 2014 at 12:40 PM, Michael wrote:
>
>
> Ista Zahn gmail.com> writes:
>
>>
>> On Mon, Nov 10, 2014 at 3:04 PM, Grant Rettke
> wisdomandwonder.com> wrote:
>> > On Mon, Nov 10, 2014 at 11:03 AM, Ista Zahn gmail.com>
> wrote:
>> >> O
Ista Zahn gmail.com> writes:
>
> On Mon, Nov 10, 2014 at 3:04 PM, Grant Rettke
wisdomandwonder.com> wrote:
> > On Mon, Nov 10, 2014 at 11:03 AM, Ista Zahn gmail.com>
wrote:
> >> On Mon, Nov 10, 2014 at 11:23 AM, Charles C. Berry
ucsd.edu> wrote:
> >>> On Mon, 10 Nov 2014, Andreas Leha wr
Sebastien Vauban writes:
>
> "Charles C. Berry" wrote:
> > I find myself writing an inline src block, then typing `C-c C-c C-x u'
> > to view
> > and then remove the result, then revise, and repeat. I'd be happy to
> > just leave
> > it in the document.
>
> What command are you calling with
"Charles C. Berry" wrote:
> I find myself writing an inline src block, then typing `C-c C-c C-x u' to view
> and then remove the result, then revise, and repeat. I'd be happy to just
> leave
> it in the document.
What command are you calling with the above?
Best regards,
Seb
--
Sebastien Vau
On Mon, Nov 10, 2014 at 7:53 PM, Ista Zahn wrote:
> The problem is that I don't want
> blocks to be evaluated on export (too time consuming in many cases).
> So I turn that off, and either evaluate the blocks one at a time (I'm
> aware of the dangers of this, not my point here) or call
> org-babel
On Mon, Nov 10, 2014 at 3:04 PM, Grant Rettke wrote:
> On Mon, Nov 10, 2014 at 11:03 AM, Ista Zahn wrote:
>> On Mon, Nov 10, 2014 at 11:23 AM, Charles C. Berry wrote:
>>> On Mon, 10 Nov 2014, Andreas Leha wrote:
>>
>> [snip]
>>
>>>
>>
>> Nonetheless, from a literate programming perspecti
On Mon, Nov 10, 2014 at 2:45 PM, Thomas S. Dye wrote:
> Grant Rettke writes:
>
>>
>> My approach here has been to use "hidden" source blocks that aren't
>> exported but make it
>> really easy to see the result during development. These settings
>> should work on any configuration,
>> so I didn't
Grant Rettke writes:
>
> My approach here has been to use "hidden" source blocks that aren't
> exported but make it
> really easy to see the result during development. These settings
> should work on any configuration,
> so I didn't include mine here.
I think you've set the :session header argum
On Mon, Nov 10, 2014 at 11:03 AM, Ista Zahn wrote:
> On Mon, Nov 10, 2014 at 11:23 AM, Charles C. Berry wrote:
>> On Mon, 10 Nov 2014, Andreas Leha wrote:
>
> [snip]
>
>>
>
> Nonetheless, from a literate programming perspective, I think that
> replaceable (and raw) inline results are
On Mon, Nov 10, 2014 at 11:23 AM, Charles C. Berry wrote:
> On Mon, 10 Nov 2014, Andreas Leha wrote:
[snip]
>
Nonetheless, from a literate programming perspective, I think that
replaceable (and raw) inline results are definitely desirable.
Regardless of the state of their imp
On Mon, 10 Nov 2014, Andreas Leha wrote:
Hi Sebastien,
Sebastien Vauban writes:
Andreas Leha wrote:
Sebastien Vauban writes:
Andreas Leha wrote:
For me, that's the correct behavior, as inline code blocks are
*only expected to be evaluated during export*.
I disagree here.
[snip]
N
Hi Sebastien,
Sebastien Vauban writes:
> Andreas Leha wrote:
>> Sebastien Vauban writes:
>>> Andreas Leha wrote:
> For me, that's the correct behavior, as inline code blocks are
> *only expected to be evaluated during export*.
I disagree here.
>>>
>>> Though, this is what Eric
Andreas Leha wrote:
> Sebastien Vauban writes:
>> Andreas Leha wrote:
For me, that's the correct behavior, as inline code blocks are
*only expected to be evaluated during export*.
>>>
>>> I disagree here.
>>
>> Though, this is what Eric Schulte wrote:
>>
>> ┌
>> │ Currently inlin
Hi,
Sebastien Vauban writes:
> Andreas Leha wrote:
>>> For me, that's the correct behavior, as inline code blocks are *only
>>> expected to be evaluated during export*.
>>
>> I disagree here. As limiting the use of inline code to
>> eval-on-export-only renders all the org-babel-execute-subtree a
Andreas Leha wrote:
>> For me, that's the correct behavior, as inline code blocks are *only
>> expected to be evaluated during export*.
>
> I disagree here. As limiting the use of inline code to
> eval-on-export-only renders all the org-babel-execute-subtree and
> related functionality useless.
T
Hi
Sebastien Vauban writes:
> Nicolas Goaziou wrote:
>> Hello,
>>
>> mcg writes:
>>
>>> I use inline code for simple calculations to insert numeric results into
>>> text apart from "normal" code blocks for more complex calculations and
>>> graphics (all in R).
>>>
>>>
>>> The :results replace op
Nicolas Goaziou wrote:
> Hello,
>
> mcg writes:
>
>> I use inline code for simple calculations to insert numeric results into
>> text apart from "normal" code blocks for more complex calculations and
>> graphics (all in R).
>>
>>
>> The :results replace option is not working for inline code, even
Hello,
mcg writes:
> I use inline code for simple calculations to insert numeric results into
> text apart from "normal" code blocks for more complex calculations and
> graphics (all in R).
>
>
> The :results replace option is not working for inline code, even if I
> explicitly set it in the cod
Hello,
I use inline code for simple calculations to insert numeric results into
text apart from "normal" code blocks for more complex calculations and
graphics (all in R).
The :results replace option is not working for inline code, even if I
explicitly set it in the code block. So I get
#+PROP
19 matches
Mail list logo
