Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

2020-11-01 Thread 吴锐扬
Can confirm that. Thanks for your work!

Best,
Ruiyang

> On Nov 1, 2020, at 4:44 PM, Kyle Meyer  wrote:
> 
> Kyle Meyer writes:
> 
>> It looks like the query went away with dbb375fdf (Simplify Babel calls
>> evaluation, 2016-06-16), which was included in the 9.0 release.  Based
>> on a quick glance at that commit, I don't think that was an intentional
>> change.
>> 
>> I won't take a closer look at this until at least this weekend, though.
>> I'd be very happy if someone beat me to it.
> 
> Should be fixed by 20374f69e.  That includes a regression test that will
> hopefully prevent an unintended change in either direction (no prompting
> or repeat prompting).




Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

2020-11-01 Thread Kyle Meyer
Kyle Meyer writes:

> It looks like the query went away with dbb375fdf (Simplify Babel calls
> evaluation, 2016-06-16), which was included in the 9.0 release.  Based
> on a quick glance at that commit, I don't think that was an intentional
> change.
>
> I won't take a closer look at this until at least this weekend, though.
> I'd be very happy if someone beat me to it.

Should be fixed by 20374f69e.  That includes a regression test that will
hopefully prevent an unintended change in either direction (no prompting
or repeat prompting).



Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

2020-10-29 Thread Achim Gratz
Berry, Charles" via "General discussions about Org-mode. writes:
> FWIW, it doesn't seem like an accident. You might ping the author of this 
> commit:

No, that change was to suppress an _additional_ confirmation that was
triggered by some internal implementation details.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada




Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

2020-10-29 Thread Berry, Charles
Just on a whim, I changed `org-babel-exp-results' by deleting


  (let (org-confirm-babel-evaluate-NOT)

and the matching right parenthesis.

Now I get a single prompt to confirm evaluation using Ruiyang's ECM.

HTH,

Chuck
> On Oct 28, 2020, at 8:16 PM, Kyle Meyer  wrote:
> 
> 吴锐扬 writes:
> 
>> The author explained his motivation for the commit in the mailing list 
>> before it got applied:
>> 
>>> That's because lob calls get wrapped internally in an anonymous
>>> emacs-lisp source block that then feeds through the result from the
>>> actual call as elisp.  The attached patch should suppress the
>>> confirmation for the wrapper call.  To the best of my knowledge nothing
>>> dangerous can happen with that evaluation and all confirmations for the
>>> call stack down from there have already taken place according to the
>>> users' setup.
> 
> Just for reference: it looks like that's
> 
>  
> https://urldefense.com/v3/__https://orgmode.org/list/87k3oaw7jz.fsf@Rainer.invalid__;!!LLK065n_VXAQ!29k-PVwb9XnRUW2w0NBea_sA5uaG3P1Ck0lJ_EyddjelOaIrJGxmvvR28RAyZpjHiQ$
>  
> 
>> If I understand correctly, executing a lob call would trigger two user
>> confirmations in the past, and this commit was meant to suppress one
>> of the two confirmations. (I may be wrong since I am a fairly new user
>> of org mode.)
> 
> Thanks for digging.  Indeed, if you go back to the parent of 56bf3d789
> (Babel: avoid superfluous confirmation for internal wrapper,
> 2013-04-10), there are two queries.  On that commit, there is one.
> 
>> Now there is no confirmation at all. IMHO, there should be exactly
>> one confirmation ideally.
> 
> It looks like the query went away with dbb375fdf (Simplify Babel calls
> evaluation, 2016-06-16), which was included in the 9.0 release.  Based
> on a quick glance at that commit, I don't think that was an intentional
> change.
> 
> I won't take a closer look at this until at least this weekend, though.
> I'd be very happy if someone beat me to it.



Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

2020-10-28 Thread Kyle Meyer
吴锐扬 writes:

> The author explained his motivation for the commit in the mailing list before 
> it got applied:
>
>> That's because lob calls get wrapped internally in an anonymous
>> emacs-lisp source block that then feeds through the result from the
>> actual call as elisp.  The attached patch should suppress the
>> confirmation for the wrapper call.  To the best of my knowledge nothing
>> dangerous can happen with that evaluation and all confirmations for the
>> call stack down from there have already taken place according to the
>> users' setup.

Just for reference: it looks like that's

  https://orgmode.org/list/87k3oaw7jz.fsf@Rainer.invalid

> If I understand correctly, executing a lob call would trigger two user
> confirmations in the past, and this commit was meant to suppress one
> of the two confirmations. (I may be wrong since I am a fairly new user
> of org mode.)

Thanks for digging.  Indeed, if you go back to the parent of 56bf3d789
(Babel: avoid superfluous confirmation for internal wrapper,
2013-04-10), there are two queries.  On that commit, there is one.

> Now there is no confirmation at all. IMHO, there should be exactly
> one confirmation ideally.

It looks like the query went away with dbb375fdf (Simplify Babel calls
evaluation, 2016-06-16), which was included in the 9.0 release.  Based
on a quick glance at that commit, I don't think that was an intentional
change.

I won't take a closer look at this until at least this weekend, though.
I'd be very happy if someone beat me to it.



Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

2020-10-28 Thread 吴锐扬
The author explained his motivation for the commit in the mailing list before 
it got applied:

> That's because lob calls get wrapped internally in an anonymous
> emacs-lisp source block that then feeds through the result from the
> actual call as elisp.  The attached patch should suppress the
> confirmation for the wrapper call.  To the best of my knowledge nothing
> dangerous can happen with that evaluation and all confirmations for the
> call stack down from there have already taken place according to the
> users' setup.

If I understand correctly, executing a lob call would trigger two user 
confirmations in the past, and this commit was meant to suppress one of the two 
confirmations. (I may be wrong since I am a fairly new user of org mode.) Now 
there is no confirmation at all. IMHO, there should be exactly one confirmation 
ideally.

But you are right, I should just copy the author on this.

Thanks,
Ruiyang

> On Oct 28, 2020, at 10:26 AM, Berry, Charles  wrote:
> 
> FWIW, it doesn't seem like an accident. You might ping the author of this 
> commit:
> 
> $ git log -S "(let (org-confirm-babel-evaluate)"
> commit 56bf3d789146fcd3c9f82d875de28c394fe593a0
> Author: Achim Gratz 
> Date:   Wed Apr 10 20:28:31 2013 +0200
> 
>Babel: avoid superfluous confirmation for internal wrapper
> 
>* lisp/ob-exp.el (org-babel-exp-results): Suppress user confirmation
>  of the emacs-lisp wrapper execution around a lob call.
> 
>* lisp/ob-lob.el (org-babel-lob-execute): Suppress user confirmation
>  of the emacs-lisp wrapper execution around a lob call.
> 
> 
> 
> HTH,
> 
> Chuck
> 
>> On Oct 28, 2020, at 4:32 AM, Eric S Fraga  wrote:
>> 
>> On Wednesday, 14 Oct 2020 at 16:18, 吴锐扬 wrote:
>>> I have org-confirm-babel-evaluate set to t by default. With this, I
>>> expect to be queried with the execution of every code block or lob
>>> call. However, this does not happen when exporting lob calls (to latex
>>> for example). Here is an example:
>> 
>> Confirmed with fairly recent org from git with
>> org-confirm-babel-evaluate set to t.  Does seem a little strange.  It
>> doesn't bother me much as I don't export org files that I haven't
>> created myself but it does appear to be a hole.
>> 
>> -- 
>> : Eric S Fraga via Emacs 28.0.50, Org release_9.4-61-ga88806.dirty
>> 
>> 
> 




Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

2020-10-28 Thread Berry, Charles
FWIW, it doesn't seem like an accident. You might ping the author of this 
commit:

$ git log -S "(let (org-confirm-babel-evaluate)"
commit 56bf3d789146fcd3c9f82d875de28c394fe593a0
Author: Achim Gratz 
Date:   Wed Apr 10 20:28:31 2013 +0200

Babel: avoid superfluous confirmation for internal wrapper

* lisp/ob-exp.el (org-babel-exp-results): Suppress user confirmation
  of the emacs-lisp wrapper execution around a lob call.

* lisp/ob-lob.el (org-babel-lob-execute): Suppress user confirmation
  of the emacs-lisp wrapper execution around a lob call.



HTH,

Chuck

> On Oct 28, 2020, at 4:32 AM, Eric S Fraga  wrote:
> 
> On Wednesday, 14 Oct 2020 at 16:18, 吴锐扬 wrote:
>> I have org-confirm-babel-evaluate set to t by default. With this, I
>> expect to be queried with the execution of every code block or lob
>> call. However, this does not happen when exporting lob calls (to latex
>> for example). Here is an example:
> 
> Confirmed with fairly recent org from git with
> org-confirm-babel-evaluate set to t.  Does seem a little strange.  It
> doesn't bother me much as I don't export org files that I haven't
> created myself but it does appear to be a hole.
> 
> -- 
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4-61-ga88806.dirty
> 
> 



Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

2020-10-28 Thread Eric S Fraga
On Wednesday, 14 Oct 2020 at 16:18, 吴锐扬 wrote:
> I have org-confirm-babel-evaluate set to t by default. With this, I
> expect to be queried with the execution of every code block or lob
> call. However, this does not happen when exporting lob calls (to latex
> for example). Here is an example:

Confirmed with fairly recent org from git with
org-confirm-babel-evaluate set to t.  Does seem a little strange.  It
doesn't bother me much as I don't export org files that I haven't
created myself but it does appear to be a hole.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4-61-ga88806.dirty



Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

2020-10-27 Thread 吴锐扬
This is just a follow up to see if anyone have insights on this matter. Thanks

Ruiyang

> On Oct 14, 2020, at 1:18 PM, 吴锐扬  wrote:
> 
> Hi,
> 
> I have org-confirm-babel-evaluate set to t by default. With this, I expect to 
> be queried with the execution of every code block or lob call. However, this 
> does not happen when exporting lob calls (to latex for example). Here is an 
> example:
> __
> 
> 1. Exporting code block (with evaluation)
> #+name: foo
> #+begin_src emacs-lisp :exports both
>  (message "hello world!")
> #+end_src
> 
> When exporting this to latex, I get queried as expected. And there is no way 
> to suppress the query unless I change org-confirm-babel-evaluate to nil.
> 
> 2. Exporting lob call
> #+name: foo
> #+begin_src emacs-lisp
>  (message "hello world!")
> #+end_src
> 
> #+call: foo()
> 
> When exporting this to latex, I don’t get queried. This seems dangerous to me.
> __
> 
> I find it hard to explain this inconsistency. If org-confirm-babel-evaluate 
> is designed to be a protective layer, then a user might export an org file 
> that includes malicious code along with a lob call, while unawarely execute 
> that code without being warned. This seems to defeat the purpose of 
> org-confirm-babel-evaluate.
> 
> As I searched the archive, I found this change was introduced in the 
> following thread: 
> https://lists.gnu.org/archive/html/emacs-orgmode/2013-04/msg00764.html
> 
> + (let (org-confirm-babel-evaluate)
> +   (org-babel-execute-src-block nil info))
> 
> Do you think this is the intended behavior of org-confirm-babel-evaluate, or 
> am I missing something?
> 
> Thanks,
> Ruiyang
> 




Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

2020-10-14 Thread 吴锐扬
Hi,

I have org-confirm-babel-evaluate set to t by default. With this, I expect to 
be queried with the execution of every code block or lob call. However, this 
does not happen when exporting lob calls (to latex for example). Here is an 
example:
__

1. Exporting code block (with evaluation)
#+name: foo
#+begin_src emacs-lisp :exports both
  (message "hello world!")
#+end_src

When exporting this to latex, I get queried as expected. And there is no way to 
suppress the query unless I change org-confirm-babel-evaluate to nil.

2. Exporting lob call
#+name: foo
#+begin_src emacs-lisp
  (message "hello world!")
#+end_src

#+call: foo()

When exporting this to latex, I don’t get queried. This seems dangerous to me.
__

I find it hard to explain this inconsistency. If org-confirm-babel-evaluate is 
designed to be a protective layer, then a user might export an org file that 
includes malicious code along with a lob call, while unawarely execute that 
code without being warned. This seems to defeat the purpose of 
org-confirm-babel-evaluate.

As I searched the archive, I found this change was introduced in the following 
thread: https://lists.gnu.org/archive/html/emacs-orgmode/2013-04/msg00764.html

+ (let (org-confirm-babel-evaluate)
+   (org-babel-execute-src-block nil info))

Do you think this is the intended behavior of org-confirm-babel-evaluate, or am 
I missing something?

Thanks,
Ruiyang