[O] Contribution of a :confirm-evaluate flag to src blocks
Hi All, First time contributing here, so apologies if I haven't gotten this quite right. As part of my employment I have an org document I have written contains a number of restclient and bash code blocks. The results of some of these src blocks are fed into other src blocks, and having to input "y" multiple times when trying to hit a REST api quickly became cumbersome. I also found the method of supplying a new org-confirm-babel-evaluate to disable the "ask to execute" behavior on a per language basis to be too crude. Therefore, I would like to introduce a new flag for src blocks ":confirm-evaluate", where a value of "n", "no", "f", or "false" will disable the "ask to execute" behavior for that specific block. I believe that this is a safer behavior compared to disabling "ask-to-execute" on a per language basis, and adds convenience to src blocks for literate programming. Thanks for your time, and I welcome any feedback! Sincerely, Mack From d05f12b3dc671065e29ebcd9cf5a10df00d1e5e9 Mon Sep 17 00:00:00 2001 From: Bligh Date: Mon, 15 Jul 2019 17:28:00 -0700 Subject: [PATCH] ob-core.el: Add confirm-evaluate flag to src blocks * lisp/ (org-babel-execute-src-block): add a flag :confirm-evaluate that allows the org-babel-confirm-evaluate behaviour to be disabled on a per block basis, rather than only on a per language basis. TINYCHANGE --- lisp/ob-core.el | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index a4b2294d7..3167f165e 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -662,7 +662,17 @@ block." (let ((result (org-babel-read-result))) (message (replace-regexp-in-string "%" "%%" (format "%S" result))) result))) - ((org-babel-confirm-evaluate info) + ;; Use :confirm-evaluate flag to determine if a code block should ask the user to evaluate it + ((let* ((inputted (cdr (assq :confirm-evaluate params +(if inputted +(let* ((inputted-confirm-evaluate (downcase inputted)) + (confirm-evaluate (not (or (string= "false" inputted-confirm-evaluate) + (string= "f" inputted-confirm-evaluate) + (string= "n" inputted-confirm-evaluate) + (string= "no" inputted-confirm-evaluate) + + (if confirm-evaluate (org-babel-confirm-evaluate info) "true")) + (org-babel-confirm-evaluate info))) (let* ((lang (nth 0 info)) (result-params (cdr (assq :result-params params))) ;; Expand noweb references in BODY and remove any -- 2.21.0
[O] Bug: Scheduling capture with a single line capture template [9.2.4 (9.2.4-10-g3b006f-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20190715/)]
Hi all,
When using a single line capture template for an entry, the indirect buffer
where the capture editing occurs restrains itself to that single line. As a
consequence, scheduling during capture is not visible in the capture buffer.
I’m not really sure this is technically unexpected. But it is certainly
inconvenient. In case it is expected behavior though, if anyone has any
thoughts on how to circumvent it, it would be appreciated.
Steps to reproduce:
Start =emacs -Q=, and eval for basic setup:
#+begin_src emacs-lisp
(package-initialize)
(setq org-capture-templates
'(("t" "TODO entry" entry
(file+headline "~/org/notes.org" "Capture")
"** TODO %?"
:empty-lines 1)))
#+end_src
Where file "~/org/notes.org" has the following contents:
#+begin_src org
,* Previous heading
,* Capture
,* Following heading
#+end_src
Now capture a "TODO entry" task with =M-x org-capture RET t=. Once there,
write
something for the heading if you like, like "test", but try to schedule this
captured item with =C-c C-s=. Hit return for today’s date and note that the
scheduling information is not visible in the capture buffer (it is present in
"notes.org", of course).
Note that I use =:empty-lines 1= in the capture template, so technically there
is a line following the heading in the file (if you visit "notes.org" in
another window/frame along the capture process, you will see that this is
indeed the case). I also cannot add a newline manually in the template (with,
"** TODO %?\n"), for it is ignored, unless there is some content after it.
Again, I’m not sure if this is technically unexpected behavior, but I thought
it worth reporting. And, in case it is as it should be, just let me know.
Best regards,
Gustavo Barros.
Emacs : GNU Emacs 26.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
of 2019-04-22
Package: Org mode version 9.2.4 (9.2.4-10-g3b006f-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20190715/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-mode-hook '(#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-show-all append local]
5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-babel-show-result-all
append local]
5]
org-babel-result-hide-spec org-babel-hide-all-hashes
org-eldoc-load)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 "\n\n(fn
ENTRY)"]
org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php" . php)
("C" . c) ("C++" . c++) ("asymptote" . asy)
("bash" . sh) ("beamer" . latex) ("calc" . fundamental)
("cpp" . c++) ("ditaa" . artist) ("dot" . fundamental)
("elisp" . emacs-lisp) ("ocaml" . tuareg)
("screen" . shell-script) ("shell" . sh)
("sqlite" . sql))
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("id" :follow org-id-open)
("eww" :follow eww :store org-eww-store-link)
("rmail" :follow org-rmail-open :store
org-rmail-store-link)
("mhe" :follow org-mhe-open :store org-mhe-store-link)
("irc" :follow org-irc-visit :store org-irc-store-link
:export org-irc-export)
("info" :follow org-info-open :export org-info-export
:store org-info-store-link)
("gnus" :follow org-gnus-open :store
org-gnus-store-link)
("docview" :follow org-docview-open :export
org-docview-export :store org-docview-store-link)
("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
("bbdb" :follow org-bbdb-open :export org-bbdb-export
:complete org-bbdb-complete-link :store
org-bbdb-s
[O] commenting items inconsistent?
1) ichigo 2) futago - commenting the top level item does not preserve the list, but strangely, commenting this subitem is ok. 3) migoto my preference is the subitem behavior. but in any case is this inconsistent? please note that i am using an old version of org [because capture inserts blank lines in recent versions and i haven't figured out] so this might have been fixed. thanks! -- The Kafka Pandemic What is misopathy? https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html The disease DOES progress. MANY people have died from it. And ANYBODY can get it at any time.
Re: [O] Contribution of a :confirm-evaluate flag to src blocks
Hi Mackenzie, Mackenzie Bligh writes: > First time contributing here, so apologies if I haven't gotten this quite > right. Great, thanks for sending the patch! > The results of some > of these src blocks are fed into other src blocks, and having to input "y" > multiple times when trying to hit a REST api quickly became cumbersome. I > also found the method of supplying a new org-confirm-babel-evaluate to > disable the "ask to execute" behavior on a per language basis to be too > crude. Therefore, I would like to introduce a new flag for src blocks > ":confirm-evaluate", where a value of "n", "no", "f", or "false" will > disable the "ask to execute" behavior for that specific block. I'm not much of a Babel user, but I wonder whether a better option would be to extend :eval with a value that means "eval but don't query". org-babel-check-confirm-evaluate could then consider this when binding `query'. That seems like it would serve the same purpose while avoiding adding a new header argument. What do you think? -- Kyle
[O] org-ref question: create a note from a bibliography entry
Hello, I have a question about org-ref. Is there a way to directly create a note when being inside a bibliography entry? I currently insert a cite link and using it I can create the note, but I would like to skip the "insert a cite link" part. Thanks, Alan signature.asc Description: PGP signature
