emacs-orgmode
[Top][All Lists]
Advanced

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]