Re: [Interest] Determanistic Org IDs
Hi All, Noticed some autoformatting happened on send. This is how the cons paragraph /should/ read (with a minor correction as well). *In last email* Cons: - Inceased chance of ID collisions across files Longer IDs I - think this could make a nice option for export settings. I'm - aware of the 9.5 feature freeze, but thought I'd mention the - idea to see if there's any interest in it. *Should be* Cons: - Inceased chance of ID collisions across files - Longer IDs I think this could make a nice option for export settings. I'm aware of the 9.4 feature freeze, but thought I'd mention the idea to see if there's any interest in it. Hope that makes things clearer. Please do let me know what you think, this would be my second contribution, so I still very much feel like I'm finding my feet. All the best, Timothy.
Re: [PATCH] Use completing-read-multiple for org-set-tags-command
Clemens writes: > Usage of org-set-tags-command can be improved by using > completing-read-multiple so you continue to get completion after the > first tag. > > This is my first contribution to org I followed > https://orgmode.org/worg/org-contribute.html and hope I got everything > right. Thanks! You got the process right. Note, though, that org-set-tags-command already supports completing multiple tags through org-tags-completion-function, which it passes as the COLLECTION argument to completing-read. In order to see that in action, you may need to tell the completion library you use to fall back to the built-in completing-read. As an example, I use Helm and have this in my configuration: (add-to-list 'helm-completing-read-handlers-alist '(org-set-tags-command))
Re: [PATCH] lisp/ob-core.el: pass expanded body to org-confirm-babel-evaluate
Tom Gillespie writes: > This is a patch to improve the behavior of > org-babel-check-confirm-evaluate and the usefulness of > org-confirm-babel-evaluate when a function is provided. Thank you. > This commit changes the behavior of org-babel-check-confirm-evaluate > so that org-confirm-babel-evaluate receives the fully expanded code to > be evaluated. This is important because there is no easy way to expand > noweb references inside org-confirm-babel-evaluate without calling > org-babel-get-src-block-info a second time. It is also important > because the current behavior makes it possible for code lurking behind > noweb references to change without the user being able to detect those > changes if they trust org-confirm-babel-evaluate is receiving the > actual body of the code that will be evalulated. I find that convincing. I'd guess that a org-confirm-babel-evaluate function would always want to see expanded noweb references. This doesn't mention coderefs, though, and the case there seems less clear. If there's not a strong reason to strip coderefs, then the new function wouldn't be necessary, and -check-confirm-evaluate could instead go with the pattern used elsewhere: (if (org-babel-noweb-p (nth 2 info) :eval) (org-babel-expand-noweb-references info) (nth 1 info)) (Perhaps it'd be worth adding a -maybe-expand variant of -expand-noweb-references since there are a good number of spots that do the same params check before calling -expand-noweb-references.) > These changes were made in such a way as to minimize changes to the > existing functions, however they come at the cost of making two calls > to org-babel-get-body-to-eval [...] Or potentially three calls to -get-body-to-eval: one call with the -check-evaluate call in -execute-src-block, one with the -confirm-evaluate in -execute-src-block, and then the direct call to -get-body-to-eval in -execute-src-block. > [...] since passing the expanded body through to > org-confirm-babel-evaluate would either require appending it to the > info list or changing the function signatures of > org-babel-confirm-evaluate and org-babel-check-confirm-evaluate which > is undesireable. Furthermore, to compute the expanded body only once > would require switching from using cond in org-babel-execute-src-block > to using a series of nested ifs. This change can be made, but starting > from the current implementation will provide a working reference for > comparison rather than trying to make all the changes at the same > time. An option not mentioned above is to replace (nth 1 info) with the expanded body upstream of (when (org-babel-check-evaluate info) ...). Modifying the body in INFO is admittedly not pretty, but it's in line with what is done elsewhere (e.g., -expand-src-block, -exp-process-buffer, -load-in-session), as well as with how other INFO elements in -execute-src-block are handled. In fact, -execute-src-block did modify (nth 1 info) before 3b3fc520a (Fix coderef handling in source blocks, 2016-08-28), though too late to affect calls to a org-confirm-babel-evaluate function. Quickly checking the tests added in that commit as well as the example in the message [0] that prompted that commit, modifying (nth 1 info) didn't seem to break the fix there. [0] https://orgmode.org/list/87mvjyoja2.fsf@dell-desktop.WORKGROUP
Re: Bug: org-babel python with :results value sends function definition with a statement after a for loop to the shell incorrectly [9.3.6 (9.3.6-elpa @ /home/username/.emacs.d/elpa/org-9.3.6/)]
> I redid the test but loaded the lastest org-mode and there was no > error. This means you probably don't need to debug this. It has been > fixed in the latest version, but the fix hasn't been updated in the > elpa package yet. you can either wait for the next release or pull > the latest code from the repo. Thanks for checking this Ian, I believe that this issue would have been fixed by this patch: https://orgmode.org/list/87pnfdo88v@gmail.com/ But I've been too swamped to check.
Re: [PATCH] Use completing-read-multiple for org-set-tags-command
Find the updated patch attached.
Clemens
>From 1b50d7450fb23110603792e63c329d7db3115ae8 Mon Sep 17 00:00:00 2001
From: Clemens Radermacher
Date: Sun, 19 Jul 2020 14:30:37 +0200
Subject: [PATCH] org.el: Use `completing-read-multiple' for
`org-set-tags-command'
* lisp/org.el (org-set-tags-command): Use `completing-read-multiple'
when prompting for tags.
* testing/lisp/test-org.el: Update tests to use
`completing-read-multiple' too.
---
lisp/org.el | 17 +++--
testing/lisp/test-org.el | 40
2 files changed, 31 insertions(+), 26 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index 12a853bd6..968883401 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -11819,6 +11819,7 @@ (defun org--align-tags-here (to-col)
;; it now points to BLANK-START. Use COLUMN instead.
(if in-blank? (org-move-to-column column) (goto-char origin))
+(defvar crm-separator)
(defun org-set-tags-command ( arg)
"Set the tags for the current visible entry.
@@ -11877,12 +11878,16 @@ (defun org-set-tags-command ( arg)
inherited-tags
table
(and org-fast-tag-selection-include-todo org-todo-key-alist))
- (let ((org-add-colon-after-tag-completion (< 1 (length table
- (org-trim (completing-read
-"Tags: "
-#'org-tags-completion-function
-nil nil (org-make-tag-string current-tags)
-'org-tags-history)))
+ (let ((org-add-colon-after-tag-completion (< 1 (length table)))
+ (crm-separator"[ ]*:[ ]*"))
+ (org-trim
+ (mapconcat #'identity
+ (completing-read-multiple
+ "Tags: "
+ #'org-tags-completion-function
+ nil nil (org-make-tag-string current-tags)
+ 'org-tags-history)
+ ":")))
(org-set-tags tags)
;; `save-excursion' may not replace the point at the right
;; position.
diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index 4f8c74539..32be5ad4a 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -6844,8 +6844,8 @@
(should
(equal "* H1 :foo:"
(org-test-with-temp-text "* H1"
- (cl-letf (((symbol-function 'completing-read)
- (lambda ( args) ":foo:")))
+ (cl-letf (((symbol-function 'completing-read-multiple)
+ (lambda ( args) '(":foo:"
(let ((org-use-fast-tag-selection nil)
(org-tags-column 1))
(org-set-tags-command)))
@@ -6854,8 +6854,8 @@
(should
(equal "* H1 :foo:\nContents"
(org-test-with-temp-text "* H1\nContents"
- (cl-letf (((symbol-function 'completing-read)
- (lambda ( args) ":foo:")))
+ (cl-letf (((symbol-function 'completing-read-multiple)
+ (lambda ( args) '(":foo:"
(let ((org-use-fast-tag-selection nil)
(org-tags-column 1))
(org-set-tags-command)))
@@ -6863,8 +6863,8 @@
(should-not
(equal "* H1 :foo:\nContents2"
(org-test-with-temp-text "* H1\nContents2"
- (cl-letf (((symbol-function 'completing-read)
- (lambda ( args) ":foo:")))
+ (cl-letf (((symbol-function 'completing-read-multiple)
+ (lambda ( args) '(":foo:"
(let ((org-use-fast-tag-selection nil)
(org-tags-column 1))
(org-set-tags-command)))
@@ -6873,8 +6873,8 @@
(should
(equal "* H1 :foo:"
(org-test-with-temp-text "* H1"
- (cl-letf (((symbol-function 'completing-read)
- (lambda ( args) ": foo *:")))
+ (cl-letf (((symbol-function 'completing-read-multiple)
+ (lambda ( args) '(": foo *:"
(let ((org-use-fast-tag-selection nil)
(org-tags-column 1))
(org-set-tags-command)))
@@ -6885,8 +6885,8 @@
(should
(equal "* H1 :foo:\nContents\n* H2 :foo:"
(org-test-with-temp-text "* H1\nContents\n* H2"
- (cl-letf (((symbol-function 'completing-read)
- (lambda ( args) ":foo:")))
+ (cl-letf (((symbol-function 'completing-read-multiple)
+ (lambda ( args) '(":foo:"
(let ((org-use-fast-tag-selection nil)
(org-loop-over-headlines-in-active-region t)
(org-tags-column 1))
@@ -6898,8 +6898,8 @@
(should
(equal "* H1\nContents\n* H2 :foo:"
(org-test-with-temp-text "* H1\nContents\n* H2"
- (cl-letf (((symbol-function 'completing-read)
- (lambda ( args) ":foo:")))
+ (cl-letf (((symbol-function 'completing-read-multiple)
+ (lambda ( args) '(":foo:"
(let ((org-use-fast-tag-selection nil)
(org-loop-over-headlines-in-active-region nil)
(org-tags-column 1))
@@ -6918,8 +6918,8 @@
(should
(equal ":foo:"
(org-test-with-temp-text "* "
- (cl-letf (((symbol-function 'completing-read)
- (lambda ( args) ":foo:")))
+ (cl-letf (((symbol-function 'completing-read-multiple)
+ (lambda ( args) '(":foo:"
(let ((org-use-fast-tag-selection nil)
(org-tags-column 1))
(org-set-tags-command)))
@@ -6928,8 +6928,8 @@
(should
(equal "* H1 :foo:"
(org-test-with-temp-text "* H1"
Re: [PATCH] Use completing-read-multiple for org-set-tags-command
I just noticed org has a test suit *surprise*. With my patch it fails, sorry for that I will look into it and update. Clemens I updated the tests and it's working now. Let me know if anything else is missing. Clemens
[Interest] Determanistic Org IDs
:PROPERTIES: :ID: 1161308a-ef0c-4490-bb36-13634f8de727 :END: User-agent: mu4e 1.4.10; emacs 26.3 Message-ID: <87r1t7mu52@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Received-SPF: pass client-ip=2607:f8b0:4864:20::102b; envelope-from=tecos...@gmail.com; helo=mail-pj1-x102b.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -7 X-Spam_score: -0.8 X-Spam_bar: / X-Spam_report: (-0.8 / 5.0 requ) BAYES_00=-1.9,DKIM_ADSP_CUSTOM_MED=0.001,DKIM_INVALID=0.1,DKIM_SIGNED=0.1,FREEMAIL_FROM=0.001,NML_ADSP_CUSTOM_MED=0.9,RCVD_IN_DNSWL_NONE=-0.0001,SPF_HELO_NONE=0.001,SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action Hello everyone, I have an html export of an org file checked into VCS. To try to reduce the 'noise' created by commiting the random org IDs changing each time, I took @alphapapa's unpackaged.el org-export-html-with-useful-ids-mode, tweaked it, and extended it to cover other elements. The end result it that the resulting html export is fully determanistic. While I'm quite pleased with the result, it occured to me that others might be interested in having their exports behave like this. >From my usage, these are the percieved pros/cons. Pros: - Reduced 'noise' if exported files are commited - (With HTML) links to particular elements in a file keep working across multiple versions, most of the time - (With HTML) links become more descriptive Cons: - Inceased chance of ID collisions across files Longer IDs I - think this could make a nice option for export settings. I'm - aware of the 9.5 feature freeze, but thought I'd mention the - idea to see if there's any interest in it. If you want to see what I've got happening, see https://tecosaur.github.io/emacs-config/config.html#nicer-generated-heading. Please let me know if this idea seems promising! Timothy.
Re: [PATCH] Use completing-read-multiple for org-set-tags-command
I just noticed org has a test suit *surprise*. With my patch it fails, sorry for that I will look into it and update. Clemens
Re: Support for simultaneous running clocks?
I wish this feature too. Carlo Tambuatco writes: > I don't know if anyone has suggested or is working on the ability for org > mode to > keep track of multiple running clocks simultaneously. I'd like the ability > to keep > track of, for example, how long something takes to compile while I keep > track of > how long I am working on some other project task at the same time. -- [ stardiviner ] I try to make every word tell the meaning that I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
[PATCH] Use completing-read-multiple for org-set-tags-command
Hello, Usage of org-set-tags-command can be improved by using completing-read-multiple so you continue to get completion after the first tag. This is my first contribution to org I followed https://orgmode.org/worg/org-contribute.html and hope I got everything right. I have signed the FSF documents (I have packages on ELPA). Clemens >From c8be9106110f266db774d73af4dcb6fbcef3bef8 Mon Sep 17 00:00:00 2001 From: Clemens Radermacher Date: Sun, 19 Jul 2020 14:30:37 +0200 Subject: [PATCH] org.el: Use `completing-read-multiple' for `org-set-tags-command' * lisp/org.el (org-set-tags-command): Use `completing-read-multiple' when prompting for tags. --- lisp/org.el | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 12a853bd6..e804ec7dd 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -11877,12 +11877,16 @@ (defun org-set-tags-command ( arg) inherited-tags table (and org-fast-tag-selection-include-todo org-todo-key-alist)) - (let ((org-add-colon-after-tag-completion (< 1 (length table - (org-trim (completing-read -"Tags: " -#'org-tags-completion-function -nil nil (org-make-tag-string current-tags) -'org-tags-history))) + (let ((org-add-colon-after-tag-completion (< 1 (length table))) + (crm-separator"[ ]*:[ ]*")) + (org-trim + (mapconcat #'identity + (completing-read-multiple + "Tags: " + #'org-tags-completion-function + nil nil (org-make-tag-string current-tags) + 'org-tags-history) + ":"))) (org-set-tags tags) ;; `save-excursion' may not replace the point at the right ;; position. -- 2.17.1
