[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] Pattch to org.texi: Document ":eval no"
From: |
Eric Schulte |
Subject: |
Re: [O] Pattch to org.texi: Document ":eval no" |
Date: |
Thu, 28 Jul 2011 16:57:59 -0600 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
Applied, Thanks for the patch -- Eric
"Sebastien Vauban" <address@hidden> writes:
> Hi Stephen,
>
> Stephen Eglen wrote:
>> Small patch attached, thanks Seb for pointing this out.
>>
>> Stephen
>>
>> diff --git a/doc/org.texi b/doc/org.texi
>> index 3ecf897..eb45885 100644
>> --- a/doc/org.texi
>> +++ b/doc/org.texi
>> @@ -12990,10 +12990,10 @@ permissions of the tangled file are set to make it
>> executable.
>> @subsubsection @code{:eval}
>> The @code{:eval} header argument can be used to limit the evaluation of
>> specific code blocks. @code{:eval} accepts two arguments ``never'' and
>> -``query''. @code{:eval never} will ensure that a code block is never
>> -evaluated, this can be useful for protecting against the evaluation of
>> -dangerous code blocks. @code{:eval query} will require a query for every
>> -execution of a code block regardless of the value of the
>> +``query''. @code{:eval never} (or @code{:eval no}) will ensure that a code
>> +block is never evaluated, this can be useful for protecting against the
>> +evaluation of dangerous code blocks. @code{:eval query} will require a
>> query
>> +for every execution of a code block regardless of the value of the
>> @code{org-confirm-babel-evaluate} variable.
>>
>> If this header argument is not set then evaluation is determined by the
>> value
>
> While this -- really! -- is an excellent initiative (to update the doc when
> you notice something's missing).
>
> Note that, would have better read my notes, instead of counting on my memory,
> I would have told you ":eval never". Though, I just checked, and confirm that
> ":eval no" is (for the moment) equivalent to it: see ob.el, lines 218 and 226.
>
> So, this patch makes sense -- except if Eric wants to let this option
> disappear, and only supports it in the code for backward compatibility.
>
> Best regards,
> Seb
--
Eric Schulte
http://cs.unm.edu/~eschulte/