Hi Achim,
Achim Gratz wrote:
> "Sebastien Vauban" writes:
>> Not sure to understand why you would prefer to have something that you just
>> wrote not taken into account, unlike one would expect?
>
> Because I might not have finished editing that part and just moving the
> cursor away from that li
"Sebastien Vauban"
writes:
> Not sure to understand why you would prefer to have something that you just
> wrote not taken into account, unlike one would expect?
Because I might not have finished editing that part and just moving the
cursor away from that line doesn't mean it should be acted upon
Hi Achim,
Achim Gratz wrote:
> "Sebastien Vauban" writes:
>>> You can also press C-c C-c on the #+Property line to apply it's effects.
>>
>> Everybody seems to get bitten by this at least once. Would there be a
>> possibility to avoid this extra step for the user, and have such parameters
>> autom
"Sebastien Vauban" writes:
>> You can also press C-c C-c on the #+Property line to apply it's effects.
>
> Everybody seems to get bitten by this at least once. Would there be a
> possibility to avoid this extra step for the user, and have such parameters
> automagically taken into account, without
Hi Eric,
Eric Schulte wrote:
>> especially once I realized that the Property has to be set when the
>> buffer is loaded.
>
> You can also press C-c C-c on the #+Property line to apply it's effects.
Everybody seems to get bitten by this at least once. Would there be a
possibility to avoid this ext
cbe...@tajo.ucsd.edu wrote:
>
> I've been bitten by the 'no C-c C-c' after changing a #+property line so
> many times, you would think I'd learn. :-(
>
Yup - I don't know why, but for some reason I can see it more easily
when others do it than when I do it: I sometimes spend *minutes*
bewildere
Nick Dokos writes:
> cbe...@tajo.ucsd.edu wrote:
>
>> cbe...@tajo.ucsd.edu writes:
>>
>> inline correction below.
>>
>> > Eric Schulte writes:
>> >
>> >> Matthew Landis writes:
>> >>
>> >>> tajo.ucsd.edu> writes:
>> >>>
>>
>> Eric Schulte gmx.com> writes:
>>
>> >>> Do
cbe...@tajo.ucsd.edu wrote:
> cbe...@tajo.ucsd.edu writes:
>
> inline correction below.
>
> > Eric Schulte writes:
> >
> >> Matthew Landis writes:
> >>
> >>> tajo.ucsd.edu> writes:
> >>>
>
> Eric Schulte gmx.com> writes:
>
> >>> Does this do what you want?
> >>>
>
>
> Eric,
>
> your response is threaded as a reply to Matthew, but here you have
> replied to my comment about buffer wide PROPERTY setting of :cache.
>
> Here is an example of the difficulty I face:
>
> ,
> | #+property: :cache yes
> |
> |
> | #+name: Ablock
> | #+begin_src emacs-lisp :resul
cbe...@tajo.ucsd.edu writes:
inline correction below.
> Eric Schulte writes:
>
>> Matthew Landis writes:
>>
>>> tajo.ucsd.edu> writes:
>>>
Eric Schulte gmx.com> writes:
>>> Does this do what you want?
>>>
>
> Have you looked at the :cache header argument [1],
Matthew Landis writes:
> On 3/2/2012 2:33 PM, Eric Schulte wrote:
>>
>> The above line should be #+PROPERTY: singular. That explains why
>> file-wide settings aren't working for you.
> THANK YOU. That makes it work,
Good to hear.
> especially once I realized that the Property has to be set wh
On 3/2/2012 2:33 PM, Eric Schulte wrote:
The above line should be #+PROPERTY: singular. That explains why
file-wide settings aren't working for you.
THANK YOU. That makes it work, especially once I realized that the
Property has to be set when the buffer is loaded. Now I have
#+PROPERTY:
Eric Schulte writes:
> Matthew Landis writes:
>
>> tajo.ucsd.edu> writes:
>>
>>>
>>> Eric Schulte gmx.com> writes:
>>>
>>> >>> Does this do what you want?
>>
>>> >
>>> > Have you looked at the :cache header argument [1], from my understanding
>>> > of your use case it should be exactly what
Matthew Landis writes:
> Eric Schulte gmx.com> writes:
>
>>
>> Matthew Landis isciences.com> writes:
>>
>> Have you tried this? The cache header argument has special handling of
>> code blocks with sessions to handle such cases.
>
> Fair enough! I hadn't tried it. But I did just try this e
On 3/2/2012 12:59 PM, Christophe Pouzat wrote:
Matthew,
I think that you're wrongly expecting babel's cache header argument to
behave like the argument of the same name in Sweave code chunks. Babel
will cache, in your case, the value of your code block evaluation and
there is none in your fir
Eric Schulte gmx.com> writes:
>
> Matthew Landis isciences.com> writes:
>
> Have you tried this? The cache header argument has special handling of
> code blocks with sessions to handle such cases.
Fair enough! I hadn't tried it. But I did just try this example:
---
Matthew Landis writes:
> tajo.ucsd.edu> writes:
>
>>
>> Eric Schulte gmx.com> writes:
>>
>> >>> Does this do what you want?
>
>> >
>> > Have you looked at the :cache header argument [1], from my understanding
>> > of your use case it should be exactly what you are after.
>> >
>>
>> Its a st
Matthew Landis writes:
> tajo.ucsd.edu> writes:
>
>>
>> Eric Schulte gmx.com> writes:
>>
>> >>> Does this do what you want?
>
>> >
>> > Have you looked at the :cache header argument [1], from my understanding
>> > of your use case it should be exactly what you are after.
>> >
>>
>> Its a st
tajo.ucsd.edu> writes:
>
> Eric Schulte gmx.com> writes:
>
> >>> Does this do what you want?
> >
> > Have you looked at the :cache header argument [1], from my understanding
> > of your use case it should be exactly what you are after.
> >
>
> Its a step in the right direction.
>
> It seem
Eric Schulte writes:
>>> Does this do what you want?
>>
>> No.
>>
>> When I put point under the headline and type C-c @ C-c C-e d, it prompts
>> me to evaluate each of the blocks, and when I answer 'no' to each, it
>> produces a document that omits the previously computed results.
>>
>> What I w
>> Does this do what you want?
>
> No.
>
> When I put point under the headline and type C-c @ C-c C-e d, it prompts
> me to evaluate each of the blocks, and when I answer 'no' to each, it
> produces a document that omits the previously computed results.
>
> What I want is to grab *existing* result
t...@tsdye.com (Thomas S. Dye) writes:
> cbe...@tajo.ucsd.edu writes:
>
>> I sometimes create large documents with many dozens of src blocks and
>> associated #+RESULTS.
>>
>> I'd like to be able to grab some of these results blocks and export them
>> into a document. Since revisions of the src bl
cbe...@tajo.ucsd.edu writes:
> I sometimes create large documents with many dozens of src blocks and
> associated #+RESULTS.
>
> I'd like to be able to grab some of these results blocks and export them
> into a document. Since revisions of the src blocks can change the
> results, I do not want to
I sometimes create large documents with many dozens of src blocks and
associated #+RESULTS.
I'd like to be able to grab some of these results blocks and export them
into a document. Since revisions of the src blocks can change the
results, I do not want to just and to copy and paste the results i
24 matches
Mail list logo
