Re: [BUG] Inconsistent behaviour of TODO + COMMENT + TODO dependencies + agenda? [9.5 (9.5-g0a86ad @ /home/ignacio/.emacs.d/elpa/org-9.5/)]
>> P.D: Just when I was going to send this I tried to investigate it a >> little bit more to not waste anyone's time, and I found the variable >> 'org-agenda-skip-comment-trees', which defaults to 't'. So now I see that >> if it is set to 'nil' it would not be inconsistent to me anymore, but I >> still think that the default behaviour is inconsistent, or at least >> unintituive for newcomers, and that maybe a corresponding variable like >> 'org-dependencies-skip-comment-trees' might be needed. > > This makes sense. The new variable should default to the old behaviour - > we do not want to break existing Org files relying on it. > > Patches are welcome! I was going to write one, but I have found further inconsistencies and incomplete documentation and I think we should clearly define first how we want dependencies to behave. According to the Org Mode documentation and the docstrings of `org-enforce-todo-dependencies' and `org-block-todo-from-children-or-siblings-or-parent', tasks are blocked when: 1. The task has undone children tasks. 2. A task has a parent with the property :ORDERED:, and there are undone sibling tasks prior to the current task 3. The parent of the task is blocked because it has siblings that should be done first, or is child of a blocked grandparent TODO entry." But they are actually blocked when: 1. The task has undone DESCENDANT tasks (i.e., undone children of children also block) 2. A task has a parent with the property :ORDERED:, and there are sibling tasks prior to the current task which are undone OR HAVE UNDONE DESCENDANTS 3. The parent of the task is blocked because it has siblings that should be done first, or is child of a blocked grandparent TODO entry. BUT THE TASK IS NOT BLOCKED E.G., IF ITS GRANDPARENT IS BLOCKED AND IS PARENT IS DONE OR HAS NO TODO STATE. So my other issues are: - Remarks in upper case in points 1 and 2 should be clarified in the documentation and docstrings, if that is actually the desired behaviour and not a bug. Otherwise, they should be fixed. I can do that in the same patch. - I also find inconsistent that in points 1 and 2 not only parents and children are considered for blocking but also further ancestors and descendants, but in point three only a direct chain of blocked parents is considered. What do you think about them? I'll start writing the original patch for now, let me know if you want me to address any of those points too while I'm at it. Ignacio
Re: [BUG] org-capture autoload bug? [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)]
>> Subject: [PATCH] use `set-default-toplevel-value' in `defcustom' setters >^Use > >> * lisp/ob-lilypond.el (org-babel-lilypond-commands): use >^Use >> `set-default-toplevel-value' instead of `set' or `set-default' in >> `defcustom' :set argument. >> * lisp/ob-shell.el (org-babel-shell-names): Ditto. Done. > Please don't use ditto. (what does it even mean?) It means the same thing again. I saw it in the message of the Emacs commit I referenced earlier in this thread, so I assumed it was standard practice. I have replaced it with "The same". But if the problem is that it makes it difficult to work later with the changelog, I can copy and paste. > It would be helpful to reference the relevant ML discussions. Done. Is there a standard, concise way to do this for org-mode threads? I know I can reference the Emacs discussion with just bug#54399, but I'm using long lists.gnu.org/archive/... links for org-mode. I attach the new patch (same diff, different commit message): >From c38584ea4e396f56d34ca934582c43436372b102 Mon Sep 17 00:00:00 2001 From: Ignacio Casso Date: Sat, 11 Jun 2022 18:59:15 +0200 Subject: [PATCH] Use `set-default-toplevel-value' in `defcustom' setters * lisp/ob-lilypond.el (org-babel-lilypond-commands): Use `set-default-toplevel-value' instead of `set' or `set-default' in `defcustom' :set argument. * lisp/ob-shell.el (org-babel-shell-names): The same. * lisp/org-capture.el (org-capture-templates): The same. * lisp/org-clock.el (org-clock-ask-before-exiting): The same. * lisp/org-duration.el (org-duration-units): The same. * lisp/org-faces.el (org-set-tag-faces): The same. * lisp/org-footnote.el (org-footnote-section): The same. * lisp/org-list.el (org-plain-list-ordered-item-terminator): The same. (org-list-allow-alphabetical): The same. * lisp/org.el (org-babel-do-load-languages): The same. (org-set-modules): The same. (org-export-backends): The same. (org-use-fast-todo-selection): The same. (org-enforce-todo-dependencies): The same. (org-enforce-todo-checkbox-dependencies): The same. (org-display-custom-times): The same. (org-set-packages-alist): The same. (org-set-emph-re): The same. * lisp/ox-odt.el (org-odt-schema-dir): The same. This commit fixes a bug that occurred when using an autoload function inside a let-binding for a custom variable when the feature defining both the function and the custom variable had not been loaded yet. See bug#54399 and https://lists.gnu.org/archive/html/emacs-orgmode/2022-03/msg00085.html, https://lists.gnu.org/archive/html/emacs-orgmode/2022-06/msg00226.html, --- lisp/ob-lilypond.el | 2 +- lisp/ob-shell.el | 2 +- lisp/org-capture.el | 2 +- lisp/org-clock.el| 2 +- lisp/org-duration.el | 2 +- lisp/org-faces.el| 2 +- lisp/org-footnote.el | 2 +- lisp/org-list.el | 4 ++-- lisp/org.el | 23 +++ lisp/ox-odt.el | 2 +- 10 files changed, 21 insertions(+), 22 deletions(-) diff --git a/lisp/ob-lilypond.el b/lisp/ob-lilypond.el index df128441a..dc33ebc17 100644 --- a/lisp/ob-lilypond.el +++ b/lisp/ob-lilypond.el @@ -107,7 +107,7 @@ you can leave the string empty on this case." :package-version '(Org . "8.2.7") :set (lambda (symbol value) -(set symbol value) +(set-default-toplevel-value symbol value) (setq org-babel-lilypond-ly-command (nth 0 value) org-babel-lilypond-pdf-command (nth 1 value) diff --git a/lisp/ob-shell.el b/lisp/ob-shell.el index c25941a44..4454e3b5d 100644 --- a/lisp/ob-shell.el +++ b/lisp/ob-shell.el @@ -68,7 +68,7 @@ outside the Customize interface." :group 'org-babel :type '(repeat (string :tag "Shell name: ")) :set (lambda (symbol value) - (set-default symbol value) + (set-default-toplevel-value symbol value) (org-babel-shell-initialize))) (defcustom org-babel-shell-results-defaults-to-output t diff --git a/lisp/org-capture.el b/lisp/org-capture.el index 773234967..948eb8bc6 100644 --- a/lisp/org-capture.el +++ b/lisp/org-capture.el @@ -376,7 +376,7 @@ When you need to insert a literal percent sign in the template, you can escape ambiguous cases with a backward slash, e.g., \\%i." :group 'org-capture :package-version '(Org . "9.5") - :set (lambda (s v) (set s (org-capture-upgrade-templates v))) + :set (lambda (s v) (set-default-toplevel-value s (org-capture-upgrade-templates v))) :type (let ((file-variants '(choice :tag "Filename " (file :tag "Literal") diff --git a/lisp/org-clock.el b/lisp/org-clock.el index e0c40ae23..b94c79baa 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -493,7 +493,7 @@ This variable only has effect if set with \\[customize]." (if value (add-hook 'kill-emacs-query-functions #'org-clock-kill-emacs-query) (remo
Re: [BUG] org-copy-subtree in a file with local variables marks buffer as modified [9.5.3 (release_9.5.3-6-gef41f3 @ /home/ignacio/repos/emacs/lisp/org/)]
>> - (delete-and-extract-region (point) (point-max))) >> + (undo-boundary) > >> + (setq buffer-undo-list >> + (seq-drop-while 'identity buffer-undo-list))) > > This looks fragile and can be disasterous when buffer-undo-list is > large. I agree that it is very fragile, but could you explain why is it also problematic with a large `buffer-undo-list'? I guess you mean efficiency-wise, but it would only iterate through the few items added since the call to (undo-boundary). Is there something else I'm not seeing? > Maybe just use with-silent-modifications or some ideas from there (for > example, wrapping modifications inside let-bound (buffer-undo-list t))? > We should not inhibit modification hooks though. Otherwise, it will mess > up with caching code. Done. I attach the new patch: >From 54e05dc54fe7091f2d1c7e0c44e01cf5abeb4907 Mon Sep 17 00:00:00 2001 From: Ignacio Casso Date: Sun, 12 Jun 2022 10:38:53 +0200 Subject: [PATCH] Do not mark buffer as modified with org-preserve-local-variables * lisp/org-macs.el (org-preserve-local-variables): Do not mark buffer as modified or alter `buffer-undo-list' when body does not actually modify the buffer. This commit fixes a bug with `org-copy-subtree', which marked the buffer as modified and added an entry to the undo list when the visited file had local variables. --- lisp/org-macs.el | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/lisp/org-macs.el b/lisp/org-macs.el index 19e5f42e9..c34ff3ab7 100644 --- a/lisp/org-macs.el +++ b/lisp/org-macs.el @@ -166,13 +166,19 @@ (and (re-search-backward "^[ \t]*# +Local Variables:" (max (- (point) 3000) 1) t) - (delete-and-extract-region (point) (point-max))) + (let ((buffer-undo-list t)) + (delete-and-extract-region (point) (point-max))) + (tick-counter-before (buffer-modified-tick))) (unwind-protect (progn ,@body) (when local-variables (org-with-wide-buffer (goto-char (point-max)) (unless (bolp) (insert "\n")) - (insert local-variables)) + (let ((modified (< tick-counter-before (buffer-modified-tick))) +(buffer-undo-list t)) + (insert local-variables) +(unless modified + (restore-buffer-modified-p nil (defmacro org-no-popups ( body) "Suppress popup windows and evaluate BODY." -- 2.25.1
Re: [BUG] org-copy-subtree in a file with local variables marks buffer as modified [9.5.3 (release_9.5.3-6-gef41f3 @ /home/ignacio/repos/emacs/lisp/org/)]
> buffer-modified-p is not the only parameter affected by juggling around > the local variables. There will be undo history, > buffer-chars-modified-tick, before/after-change-hooks triggered by > `org-preserve-local-variables', etc. > > However, I do not see any obvious way how your proposed change can > negatively affect all the above. Feel free to propose a patch. I've written a patch proposal. It deals with buffer-modified-p and undo history, but not the other two points you mention. I have tested it and it works, but I had never dealt before with `buffer-undo-list' so maybe there are some cases that I have not considered and for which this patch could be problematic. Let me know what you think: >From 14506bea13bf6278d95825257d90bbc3390ae8f1 Mon Sep 17 00:00:00 2001 From: Ignacio Casso Date: Sun, 12 Jun 2022 10:38:53 +0200 Subject: [PATCH] Do not mark buffer as modified with org-preserve-local-variables * lisp/org-macs.el (org-preserve-local-variables): Do not mark buffer as modified or alter `buffer-undo-list' when body does not actually modify the buffer. This commit fixes a bug with `org-copy-subtree', which marked the buffer as modified and added an entry to the undo list when the visited file had local variables. --- lisp/org-macs.el | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/lisp/org-macs.el b/lisp/org-macs.el index 19e5f42e9..64beeff53 100644 --- a/lisp/org-macs.el +++ b/lisp/org-macs.el @@ -163,16 +163,24 @@ (org-with-wide-buffer (goto-char (point-max)) (let ((case-fold-search t)) - (and (re-search-backward "^[ \t]*# +Local Variables:" + (when (re-search-backward "^[ \t]*# +Local Variables:" (max (- (point) 3000) 1) t) - (delete-and-extract-region (point) (point-max))) + (undo-boundary) + (delete-and-extract-region (point) (point-max)) + (tick-counter (buffer-modified-tick)) + modified) (unwind-protect (progn ,@body) (when local-variables + (setq modified (< tick-counter (buffer-modified-tick))) (org-with-wide-buffer (goto-char (point-max)) (unless (bolp) (insert "\n")) - (insert local-variables)) + (insert local-variables)) + (unless modified + (set-buffer-modified-p nil) + (setq buffer-undo-list + (seq-drop-while 'identity buffer-undo-list))) (defmacro org-no-popups ( body) "Suppress popup windows and evaluate BODY." -- 2.25.1
Re: org-crypt ?
Hello, I'll take this chance to bring this up again, since it's also an issue concerning org-crypt and it may be relevant if you decide to update org-crypt's documentation: https://lists.gnu.org/archive/html/emacs-orgmode/2021-12/msg00675.html. Regards, Ignacio David Masterson writes: > Ihor Radchenko writes: > >> David Masterson writes: >> >>> I think I've gotten org-crypt working, but I think some things are not >>> making sense (it might be just me): >>> >>> 1. I've set org-crypt-key to nil (symmetric encryption). >>> 2. Can I use a different encryption key for each encrypted paragraph? >> >> Yes. For each individual encrypted headline contents. Just enter >> different passwords when queried to encrypt. >> >>> 3. Does org-encrypt only ask for the key the first time? >> >> No. Strictly speaking it may depend on you GnuPG config. Not by default. >> >>> 4. Does org-decrypt only ask for the key the first time? >> >> Depends on your GnuPG config. AFAIK, GnuPG will not cache keys by default. >> >>> 5. How do they know where to get the password when they don't ask? >> >> From gpg-agent. >> >>> 6. Shouldn't org-crypt docs in org manual have examples? >> >> We can mention org-encrypt-entry/entries and org-decrypt-entry/entries. >> Would it help? > > Yes. Also, any basic config of gpg to work with. Also, a simple test > example to show what should happen to help users determine if their > heading the right way. > > Thanks
Re: [BUG] org-capture autoload bug? [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)]
> LGTM! Unless others have objections, I am inclined to merge the patch > fully. But please add changlog entries to the commit message. Done. I attach the patch with the new commit message. >From 26d157aedfaf1496174682a1f9033d83160a06c2 Mon Sep 17 00:00:00 2001 From: Ignacio Casso Date: Sat, 11 Jun 2022 18:59:15 +0200 Subject: [PATCH] use `set-default-toplevel-value' in `defcustom' setters * lisp/ob-lilypond.el (org-babel-lilypond-commands): use `set-default-toplevel-value' instead of `set' or `set-default' in `defcustom' :set argument. * lisp/ob-shell.el (org-babel-shell-names): Ditto. * lisp/org-capture.el (org-capture-templates): Ditto. * lisp/org-clock.el (org-clock-ask-before-exiting): Ditto. * lisp/org-duration.el (org-duration-units): Ditto. * lisp/org-faces.el (org-set-tag-faces): Ditto. * lisp/org-footnote.el (org-footnote-section): Ditto. * lisp/org-list.el (org-plain-list-ordered-item-terminator): Ditto. (org-list-allow-alphabetical): Ditto. * lisp/org.el (org-babel-do-load-languages): Ditto. (org-set-modules): Ditto. (org-export-backends): Ditto. (org-use-fast-todo-selection): Ditto. (org-enforce-todo-dependencies): Ditto. (org-enforce-todo-checkbox-dependencies): Ditto. (org-display-custom-times): Ditto. (org-set-packages-alist): Ditto. (org-set-emph-re): Ditto. * lisp/ox-odt.el (org-odt-schema-dir): Ditto. This commit fixes a bug that occurred when using an autoload function inside a let-binding for a custom variable when the feature defining both the function and the custom variable had not been loaded yet. --- lisp/ob-lilypond.el | 2 +- lisp/ob-shell.el | 2 +- lisp/org-capture.el | 2 +- lisp/org-clock.el| 2 +- lisp/org-duration.el | 2 +- lisp/org-faces.el| 2 +- lisp/org-footnote.el | 2 +- lisp/org-list.el | 4 ++-- lisp/org.el | 23 +++ lisp/ox-odt.el | 2 +- 10 files changed, 21 insertions(+), 22 deletions(-) diff --git a/lisp/ob-lilypond.el b/lisp/ob-lilypond.el index df128441a..dc33ebc17 100644 --- a/lisp/ob-lilypond.el +++ b/lisp/ob-lilypond.el @@ -107,7 +107,7 @@ you can leave the string empty on this case." :package-version '(Org . "8.2.7") :set (lambda (symbol value) -(set symbol value) +(set-default-toplevel-value symbol value) (setq org-babel-lilypond-ly-command (nth 0 value) org-babel-lilypond-pdf-command (nth 1 value) diff --git a/lisp/ob-shell.el b/lisp/ob-shell.el index c25941a44..4454e3b5d 100644 --- a/lisp/ob-shell.el +++ b/lisp/ob-shell.el @@ -68,7 +68,7 @@ outside the Customize interface." :group 'org-babel :type '(repeat (string :tag "Shell name: ")) :set (lambda (symbol value) - (set-default symbol value) + (set-default-toplevel-value symbol value) (org-babel-shell-initialize))) (defcustom org-babel-shell-results-defaults-to-output t diff --git a/lisp/org-capture.el b/lisp/org-capture.el index 773234967..948eb8bc6 100644 --- a/lisp/org-capture.el +++ b/lisp/org-capture.el @@ -376,7 +376,7 @@ When you need to insert a literal percent sign in the template, you can escape ambiguous cases with a backward slash, e.g., \\%i." :group 'org-capture :package-version '(Org . "9.5") - :set (lambda (s v) (set s (org-capture-upgrade-templates v))) + :set (lambda (s v) (set-default-toplevel-value s (org-capture-upgrade-templates v))) :type (let ((file-variants '(choice :tag "Filename " (file :tag "Literal") diff --git a/lisp/org-clock.el b/lisp/org-clock.el index e0c40ae23..b94c79baa 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -493,7 +493,7 @@ This variable only has effect if set with \\[customize]." (if value (add-hook 'kill-emacs-query-functions #'org-clock-kill-emacs-query) (remove-hook 'kill-emacs-query-functions #'org-clock-kill-emacs-query)) - (set symbol value)) + (set-default-toplevel-value symbol value)) :type 'boolean :package-version '(Org . "9.5")) diff --git a/lisp/org-duration.el b/lisp/org-duration.el index b242a6f2c..338ea11a9 100644 --- a/lisp/org-duration.el +++ b/lisp/org-duration.el @@ -98,7 +98,7 @@ sure to call the following command: :version "26.1" :package-version '(Org . "9.1") :set (lambda (var val) - (set-default var val) + (set-default-toplevel-value var val) ;; Avoid recursive load at startup. (when (featurep 'org-duration) (org-duration-set-regexps))) diff --git a/lisp/org-faces.el b/lisp/org-faces.el index f919a6b47..5fb6c3e07 100644 --- a/lisp/org-faces.el +++ b/lisp/org-faces.el @@ -338,7 +338,7 @@ determines if it is a foreground or a background color." (defvar org-tags-special-faces-re nil) (defun org-set-tag-faces (var value) - (set var value) + (set-default-toplevel-value var value) (if (not value) (setq org-tags-special-faces-re nil) (
Re: [BUG] org-capture autoload bug? [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)]
Hello, The bug I reported about this to the Emacs devel mailing list (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54399) has now been closed, and some documentation has been updated in commit 071722e41120. Basically, the problem is that in order for (let ((custom-variable local-value) ...) ... (defcustom custom-variable standard-value ...) ...) to work as expected with dynamic binding, `defcustom' has to set the variable with `set-default-toplevel-value'. This way, the code inside the `let' form uses local-value and the default value is set to standard-value. If `defcustom' uses `set-default' instead, it overwrites the local value, so the let-binding is useless, and after the let form is evaluated the variable is void. The problem was that `set-default-toplevel-value' is used by default, but the documentation said that the default was `set-default'. So either whoever wrote the `org-capture-templates' setter was misguided by the documentation and used `set-default', or more likely, that setter was written before the introduction of `set-default-toplevel-value' in custom.el, and was never updated. The first thing we should do is finding all uses of `set-default' in the org `defcustom' setters and replace them with `set-default-toplevel-value'. This would fix this bug and similar ones when using dynamic binding, and would not affect any other use case. Then we should decide if we want to use autoload cookies for custom variables to make this work also with lexical binding. Otherwise, code like the snippet above would produce an error in Emacs 29, and in Emacs 27 the let binding would be ignored (although at least the custom setter would work). I have no opinion regarding this last point since I don't remember what were the disadvantages of using autoload cookies for custom variables. I've prepared a patch for the first point, which I attach at the end of this email. All changes fall in one of the following cases: - `set-default' -> `set-default-toplevel-value' (as explained) - `set' -> `set-default-toplevel-value' The same, but in this cases there was another bug: If a buffer set the custom variable locally before the feature was autoloaded, the setter of the variable would not set the standard value as the default for other buffers, and would overwrite the buffer-local value. - :set 'set-default -> nothing, since it would be already the default I don't really know what most of the variables whose setter I have changed do or whether it makes any sense to use them inside a let binding, but I have made the change for all of them nevertheless, since it can not harm and could potentially fix a bug. Feel free to restrict those changes only to those variables where it makes sense, such as `org-capture-templates', if you want to keep the patch small and simple. Best regards, Ignacio [2. patch --- text/x-diff; 0001-using-set-default-toplevel-value-in-defcustom-setter.patch] >From b20e23013329fab574a4d05eb5be8cde1d43dad1 Mon Sep 17 00:00:00 2001 From: Ignacio Casso Date: Fri, 10 Jun 2022 12:39:43 +0200 Subject: [PATCH] using `set-default-toplevel-value' in `defcustom' setters --- lisp/ob-lilypond.el | 2 +- lisp/ob-shell.el | 2 +- lisp/org-capture.el | 2 +- lisp/org-clock.el| 2 +- lisp/org-duration.el | 2 +- lisp/org-faces.el| 2 +- lisp/org-footnote.el | 2 +- lisp/org-list.el | 4 ++-- lisp/org.el | 23 +++ lisp/ox-odt.el | 2 +- 10 files changed, 21 insertions(+), 22 deletions(-) diff --git a/lisp/ob-lilypond.el b/lisp/ob-lilypond.el index df128441a..dc33ebc17 100644 --- a/lisp/ob-lilypond.el +++ b/lisp/ob-lilypond.el @@ -107,7 +107,7 @@ you can leave the string empty on this case." :package-version '(Org . "8.2.7") :set (lambda (symbol value) -(set symbol value) +(set-default-toplevel-value symbol value) (setq org-babel-lilypond-ly-command (nth 0 value) org-babel-lilypond-pdf-command (nth 1 value) diff --git a/lisp/ob-shell.el b/lisp/ob-shell.el index c25941a44..4454e3b5d 100644 --- a/lisp/ob-shell.el +++ b/lisp/ob-shell.el @@ -68,7 +68,7 @@ outside the Customize interface." :group 'org-babel :type '(repeat (string :tag "Shell name: ")) :set (lambda (symbol value) -(set-default symbol value) +(set-default-toplevel-value symbol value) (org-babel-shell-initialize))) (defcustom org-babel-shell-results-defaults-to-output t diff --git a/lisp/org-capture.el b/lisp/org-capture.el index 773234967..948eb8bc6 100644 --- a/lisp/org-capture.el +++ b/lisp/org-capture.el @@ -376,7 +376,7 @@ When you need to insert a literal percent sign in the template, you can escape ambiguous cases with a backward slash, e.g., \\%i." :group 'org-capture :package-version '(Org . "9.5") - :set (lambda (s v) (set s (org-capture-upgrade-templates v))) + :set (lambda (s v) (set-default-tople
[BUG] org-copy-subtree in a file with local variables marks buffer as modified [9.5.3 (release_9.5.3-6-gef41f3 @ /home/ignacio/repos/emacs/lisp/org/)]
Hello, Copying a subtree with `org-copy-subtree' in an org file with local variables marks the buffer as modified. This is because `org-copy-subtree' calls `org-preserve-local-variables', which deletes local variables, executes some body, and then inserts them again, which results in a modified buffer even if the buffer was not modified before and the body does not modify it either, like in the case of `org-copy-subtree'. What would you think about a change like the following in the definition of `org-preserve-local-variables' to solve the issue? + (let ((modified-before-p) (buffer-modified-p)) ;; current code that deletes local variables + (unless modified-before-p (set-buffer-modified-p nil)) ;; current code that executes body + (let ((modified-after-p (buffer-modified-p))) ;; current code that restores local variables + (unless modified-after-p (set-buffer-modified-p nil Could the current code or my proposed change have any more unintended consequences, for example in the undo tree or mark ring? Sometimes when I undo or jump to the mark, the point moves to the last visible, usually folded headline of the file, even if I had not edited it recently, and I have always assumed that it's because it wants to go to the end of the buffer for some reason I've never been able to come up with or debug. Could that have something to do with this? Best regards, Ignacio Emacs : GNU Emacs 29.0.50 (build 53, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0) of 2022-05-22 Package: Org mode version 9.5.3 (release_9.5.3-6-gef41f3 @ /home/ignacio/repos/emacs/lisp/org/)
Re: [BUG] org-complex-heading-regexp should consider COMMENT keywords [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]
> Thanks! Thank you too! > I have added TINYCHANGE cookie as you don't appear to have FSF copyright I should have it, I did the paperwork for commit 2b564f504b in Emacs. Maybe I used a different email? Or maybe the problem is that now that I see it I don't have my full name configured in git. It's Ignacio Casso, and I appear in the commit author field as just Ignacio. I have fixed it now for future commits.
Re: [BUG] org-complex-heading-regexp should consider COMMENT keywords [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]
Ihor Radchenko writes: > Ignacio Casso writes: > >>> Sounds reasonable. Could you prepare a patch? >>> COMMENT should be inside a shy group and note that there might be an >>> arbitrary number of space after COMMENT string. >> >> Here it is. > > Thanks! Could you also update the org-complex-heading-regexp-format > docstring and make the commit massage conform with > https://orgmode.org/worg/org-contribute.html#commit-messages (also see > https://orgmode.org/list/87ilqz14ys.fsf@localhost)? > > Best, > Ihor Done. I attach the patch: >From 646f2a792dc5c6e6fa3933eb1d06420c86cd53c3 Mon Sep 17 00:00:00 2001 From: Ignacio Date: Fri, 6 May 2022 13:51:14 +0200 Subject: [PATCH] lisp/org.el: match COMMENT in `org-complex-heading-regexp-format' * lisp/org.el (org-set-regexps-and-options): Change `org-complex-heading-regexp-format' initialization so that the regexp it produces also matches a headline if it is commented. --- lisp/org.el | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/lisp/org.el b/lisp/org.el index 1d5fc3903..cab59b87c 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -3846,7 +3846,8 @@ expected to be bound to nil when matching against this regexp.") "Printf format to make regexp to match an exact headline. This regexp will match the headline of any node which has the exact headline text that is put into the format, but may have any -TODO state, priority and tags.") +TODO state, priority, tags, statistics cookies (at the beginning +or end of the headline title), or COMMENT keyword.") (defvar-local org-todo-line-tags-regexp nil "Matches a headline and puts TODO state into group 2 if present. @@ -4213,6 +4214,8 @@ related expressions." "\\(?: +" org-todo-regexp "\\)?" "\\(?: +\\(\\[#.\\]\\)\\)?" "\\(?: +" + ;; Headline might be commented + "\\(?:" org-comment-string " +\\)?" ;; Stats cookies can be stuck to body. "\\(?:\\[[0-9%%/]+\\] *\\)*" "\\(%s\\)" -- 2.25.1
Re: [BUG] org-complex-heading-regexp should consider COMMENT keywords [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]
> Sounds reasonable. Could you prepare a patch? > COMMENT should be inside a shy group and note that there might be an > arbitrary number of space after COMMENT string. Here it is. >From 54cd366c97bd64c226cc6fc79e125ee9f026ff66 Mon Sep 17 00:00:00 2001 From: Ignacio Date: Fri, 6 May 2022 13:51:14 +0200 Subject: [PATCH] lisp/org.el: match COMMENT in `org-complex-heading-regexp-format' --- lisp/org.el | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lisp/org.el b/lisp/org.el index 1d5fc3903..0ec717322 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -4213,6 +4213,8 @@ related expressions." "\\(?: +" org-todo-regexp "\\)?" "\\(?: +\\(\\[#.\\]\\)\\)?" "\\(?: +" + ;; Headline might be commented + "\\(?:" org-comment-string " +\\)?" ;; Stats cookies can be stuck to body. "\\(?:\\[[0-9%%/]+\\] *\\)*" "\\(%s\\)" -- 2.25.1
Re: [BUG] - Statistics cookie is part of the org heading title
I've replied to this email in the original thread about the COMMENT keyword to continue the discussion there, since it may be a little off-topic here. --Ignacio >> Still, I think it might be interesting to compare this topic with the >> one I linked in my reply, >> https://lists.gnu.org/archive/html/emacs-orgmode/2022-03/msg00293.html, >> which it's basically the same bug report but about COMMENT keywords. In >> that regard, I have tested that org-capture targets do work regardless >> of statistcs cookies. Could not something equivalent be done so that >> they also work regardless of COMMENT keywords? Feel free to reply in >> that other thread if you feel this is off-topic here. > >> This bug is related with the issue I reported in >> https://lists.gnu.org/archive/html/emacs-orgmode/2022-03/msg00293.html. The >> problem is that `org-heading-components' uses >> `org-complex-heading-regexp', which does not consider statistics >> cookies, and neither COMMENT keywords as I reported. I think it should be >> updated to consider both. > > Note that org-complex-heading-regexp-format does consider statistics > cookies, but only at the beginning/end of the headline title. > Unfortunately, it is impossible to provide generic printf format to > match a headline title with arbitrary statistics cookies inserted in the > middle of it. > > As for your other report, it is a hard one - org-complex-heading-regexp > is hard to modify because we guarantee certain match groups and its hard > to fit COMMENT in there without breaking backward-compatibility. > > I generally dislike the idea of the available plethora of analytic > regexps with numbered match groups. I am currently working on > generalised Org element matcher that provides named groups for arbitrary > Org syntax elements, including headlines. > > Best, > Ihor
[BUG] org-complex-heading-regexp should consider COMMENT keywords [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]
This topic was brought up again in https://lists.gnu.org/archive/html/emacs-orgmode/2022-05/msg00058.html, I continue the discussion here: >> Still, I think it might be interesting to compare this topic with the >> one I linked in my reply, >> https://lists.gnu.org/archive/html/emacs-orgmode/2022-03/msg00293.html, >> which it's basically the same bug report but about COMMENT keywords. In >> that regard, I have tested that org-capture targets do work regardless >> of statistcs cookies. Could not something equivalent be done so that >> they also work regardless of COMMENT keywords? Feel free to reply in >> that other thread if you feel this is off-topic here. > >> This bug is related with the issue I reported in >> https://lists.gnu.org/archive/html/emacs-orgmode/2022-03/msg00293.html. The >> problem is that `org-heading-components' uses >> `org-complex-heading-regexp', which does not consider statistics >> cookies, and neither COMMENT keywords as I reported. I think it should be >> updated to consider both. > > Note that org-complex-heading-regexp-format does consider statistics > cookies, but only at the beginning/end of the headline title. > Unfortunately, it is impossible to provide generic printf format to > match a headline title with arbitrary statistics cookies inserted in the > middle of it. > Could not something equivalent be done for COMMENT keywords and optionally match them at the beginning of the headline in `org-complex-heading-regexp-format'? Something like this: (setq org-complex-heading-regexp-format (concat "^\\(\\*+\\)" "\\(?: +" org-todo-regexp "\\)?" "\\(?: +\\(\\[#.\\]\\)\\)?" "\\(?: +" + ;; Headline might be commented + "\\(COMMENT \\)? ;; Stats cookies can be stuck to body. "\\(?:\\[[0-9%%/]+\\] *\\)*" "\\(%s\\)" "\\(?: *\\[[0-9%%/]+\\]\\)*" "\\)" "\\(?:[ \t]+\\(:[[:alnum:]_@#%%:]+:\\)\\)?" "[ \t]*$")) This would fix the problem I really cared about: being able to use a headline as capture target regardless of whether it is commented or not. Getting the headline text was never important to me, so I don't really care that much about `org-complex-heading-regexp'. > As for your other report, it is a hard one - org-complex-heading-regexp > is hard to modify because we guarantee certain match groups and its hard > to fit COMMENT in there without breaking backward-compatibility. > > I generally dislike the idea of the available plethora of analytic > regexps with numbered match groups. Do you mean that there is no way to specify an optional string in a regular expression without wrapping it in a parenthesized group, which would break the match group numbering backwards compatibility? I'm not that familiar with regular expressions, but if that's the case I completely agree with your last statement. --Ignacio
Re: [BUG] - Statistics cookie is part of the org heading title
Ihor Radchenko writes: > Samuel Wales writes: > >> some code removes it. for example creating a link to a headline using >> capture. > > Yeah. org-link--normalize-string. But it is internal function, so I would > not rely on it. > > Also, rather than relying on regexps, I would use > org-element-headline-parser, extract parsed :title property, and filter > out statistics-cookie objects. > > Best, > Ihor I replied to this bug report yesterday via the "reply via email to" button in https://lists.gnu.org/archive/html/emacs-orgmode/2022-05/msg00058.html, assuming it would send it to the org-mode list, but now I see that it was only sent to Fabian. I copy my answer at the end of this email, although when I wrote it I did not know that statistics cookies can appear anywhere in the headline and not just at the end before tags, nor about `org-element-headline-parser', so as a reply it may be no longer relevant or correct. Still, I think it might be interesting to compare this topic with the one I linked in my reply, https://lists.gnu.org/archive/html/emacs-orgmode/2022-03/msg00293.html, which it's basically the same bug report but about COMMENT keywords. In that regard, I have tested that org-capture targets do work regardless of statistcs cookies. Could not something equivalent be done so that they also work regardless of COMMENT keywords? Feel free to reply in that other thread if you feel this is off-topic here. Regards, --Ignacio Original reply: Hi Fabian, > I would like to report his behaviour as a bug: > > Example: > > * Some Heading Title [0/1] ;; cursor in this line when executing > ** TODO Some Todo Item > > -> result is "Some Heading Title [0/1]" > > -> desired result would be "Some Heading Title" > You forgot to say that you use (nth 4 (org-heading-components)) when you copied the example from emacs.stackexchange.com. > I don't see any reason why the statistics cookie should be part of the title: > it should be a separate component. I agree. This bug is related with the issue I reported in https://lists.gnu.org/archive/html/emacs-orgmode/2022-03/msg00293.html. The problem is that `org-heading-components' uses `org-complex-heading-regexp', which does not consider statistics cookies, and neither COMMENT keywords as I reported. I think it should be updated to consider both. In the meantime, I was going to suggest that you use the org parser, with (org-element-property :title (org-element-context)) which solves the problem in the case of the COMMENT keywords. But I have tested it and it does not solve it in the case of statistics cookies, so I guess the problem should be fixed in org-element.el too. Regards, -- Ignacio
Re: [BUG] link abbreviations do not work inside property drawers [9.5.2 (release_9.5.2-38-g682ccd @ /home/ignacio/repos/emacs/lisp/org/)]
Ihor Radchenko writes: > Ignacio Casso writes: > >>> A better approach could be using org-link-expand-abbrev. It is an API >>> function and should be forward-compatible. >> >> Do you mean something like this? >> >> (defun org-open-at-point-global () >> ... >> (cond ((org-in-regexp org-link-any-re) >> (org-link-open-from-string >> (org-link-expand-abbrev (match-string-no-properties 0 >> ...)) >> >> Right now that is not enough because `org-link-expand-abbrev' only works >> for links without square brackets, like "abbrev:suffix", and >> `org-link-any-re' matches links with square brackets, like >> "[[abbrev:suffix]]". That could be easily worked around in >> `org-open-at-point-global' but maybe it would be better to change >> `org-link-expand-abbrev' to work with both forms. > > Fair point. Then, the most future-proof way would be calling > org-element-link-parser. It should take care about abbrev expansion and > other edge cases. Then, you just need to use :raw-link property of the > parsed link element. > > Best, > Ihor And then we come full circle, since that is what is being done already but in a temporal buffer (so without access to `org-link-abbrev-alist-local'), and your original concerns in your first reply apply: doing it inside `org-open-at-point' would duplicate a lot of code. So I guess the issue is not as orthogonal as I though with the one of the parser and it would be complicated to fix it properly, as you said in your first email. If no one else has reported this problem or replied to this thread, I guess that probably the best thing to do is fixing this in my own config and move on for now: I'll copy here the advice that fixes it, in case anyone needs to add it to their config too: (defun my-advice (orig-fun args) (let ((org-link-abbrev-alist (append org-link-abbrev-alist org-link-abbrev-alist-local))) (apply orig-fun args))) (advice-add 'org-open-at-point-global :around 'my-advice) Best regards, and thanks for taking a look at this, --Ignacio
Re: [BUG] link abbreviations do not work inside property drawers [9.5.2 (release_9.5.2-38-g682ccd @ /home/ignacio/repos/emacs/lisp/org/)]
>> (cond ((org-in-regexp org-link-any-re) >>(let ((org-link-abbrev-alist >> (append org-link-abbrev-alist org-link-abbrev-alist-local))) >> (org-link-open-from-string (match-string-no-properties 0 >> ...) >> ... >> What do you think? > > I do not like this idea. There is also org-link-abbrev-alist-local and > potentially other variables to be introduced in future. We should not > rely too much on internal workings of ol.el. > > A better approach could be using org-link-expand-abbrev. It is an API > function and should be forward-compatible. Do you mean something like this? (defun org-open-at-point-global () ... (cond ((org-in-regexp org-link-any-re) (org-link-open-from-string (org-link-expand-abbrev (match-string-no-properties 0 ...)) Right now that is not enough because `org-link-expand-abbrev' only works for links without square brackets, like "abbrev:suffix", and `org-link-any-re' matches links with square brackets, like "[[abbrev:suffix]]". That could be easily worked around in `org-open-at-point-global' but maybe it would be better to change `org-link-expand-abbrev' to work with both forms. Let me know if you want me to send a patch implementing any of those options or any other that you see fit. Otherwise, I know enough now to fix the issue in my own config, so we can leave at that. Regards, --Ignacio
Re: [BUG] link abbreviations do not work inside property drawers [9.5.2 (release_9.5.2-38-g682ccd @ /home/ignacio/repos/emacs/lisp/org/)]
Ihor Radchenko writes: > Ignacio Casso writes: > >> So a simple solution to this would be preserving the value of >> `org-link-abbrev-alist-local' when switching to the temporal buffer. I >> think this is orthogonal to the issue of the parser, and it's a bug on >> its own, since as a user I would expect that evaluating >> `org-link-open-from-string' would use my current buffer's local values >> of variables. > > I am not sure if using current buffer in `org-link-open-from-string' is > to be expected. This function is not tied to buffer, just to string. > Imagine a situation when user function retrieves the link string from > another buffer and then calls `org-link-org-from-string' in the context > of current buffer. What you are proposing is going to change the current > behaviour of `org-link-open-from-string' beyond the discussed problem. > > Instead of changing the default behaviour of > `org-link-open-from-string', I would introduce an optional parameter > holding the desired context. The parameter can be set to an Org buffer. > That buffer's context will be used. I agree that changing the current behavior of `org-link-open-from-string' may be problematic, however I don't think that it's worth to introduce the optional argument just for this "bug". I would just use the let from I suggested: (let ((org-link-abbrev-alist (append org-link-abbrev-alist org-link-abbrev-alist-local))) ...) but instead of doing it in the definition of `org-link-open-from-string', do it in `org-open-at-point-global', like this: (cond ((org-in-regexp org-link-any-re) (let ((org-link-abbrev-alist (append org-link-abbrev-alist org-link-abbrev-alist-local))) (org-link-open-from-string (match-string-no-properties 0 ...) or in `org-open-at-point', like this: (cond ... ((memq type '(comment comment-block node-property keyword)) (let ((org-link-abbrev-alist (append org-link-abbrev-alist org-link-abbrev-alist-local))) (call-interactively #'org-open-at-point-global))) ...) What do you think? --Ignacio
Re: [BUG] link abbreviations do not work inside property drawers [9.5.2 (release_9.5.2-38-g682ccd @ /home/ignacio/repos/emacs/lisp/org/)]
Ihor Radchenko writes: > Ignacio Casso writes: > >> Link abbreviations do not work inside property drawers and are instead >> confused with internal links. The following org file illustrates this >> behavior. > > This is to be expected. org-open-at-point does the following: > >;; No valid link at point. For convenience, look if something >;; looks like a link under point in some specific places. >((memq type '(comment comment-block node-property keyword)) > (call-interactively #'org-open-at-point-global)) > > That is, links are only partially recognised inside comments, node > properties, and keywords. > >> I know that there is discussion of whether timestamps and links should >> work or not inside property drawers, but since they currently work, I >> think link abbreviations should be supported too. Let me know if you >> agree and I'll debug the issue and send a patch with a fix proposal. > > I do not think that it is an easy problem to solve properly. > > In the discussion you referenced [1] Nicolas raised the problem that we > cannot modify org-element parser to support links in more contexts as it > may create various issues (e.g. in exporter). > > Without modifying the parser, supporting abbreviations will require code > duplication or referring to internal org-element functions - a fragile > approach. > > I am currently tinkering with an idea to implement several parser > contexts, similar to optional argument in org-at-timestamp-p. > Basically, org-element parser could allow using multiple > named org-element-object-restrictions: 'agenda, 'export, 'lax, etc. > This is not ideal, as Org syntax will be more complex. However, multiple > interpretations of Org syntax are already implemented de facto (e.g. > org-at-timestamp-p). So, centralising the parsing into org-element could > be beneficial. > > Probably, the contexts might be defined by let-bound > org-element-parser-context value. > > Best, > Ihor > > [1] https://orgmode.org/list/877d8llha9@nicolasgoaziou.fr Actually, I have investigated a little bit and I think the issue is more simple than that: - Link abbreviations rely in the variables `org-link-abbrev-alist' for global abbreviations and `org-link-abbrev-alist-local' for abbreviations defined with #+LINK for a single org file. - `org-open-at-point-global' opens links with `org-link-open-from-string' as opposed to `org-open-at-point', which uses `org-link-open'. - `org-link-open-from-string' ends up using `org-link-open' too, but inside a `with-temp-buffer' form: (defun org-link-open-from-string (s arg) ... (pcase (with-temp-buffer (let ((org-inhibit-startup nil)) (insert s) (org-mode) (goto-char (point-min)) (org-element-link-parser))) (`nil (user-error "No valid link in %S" s)) (link (org-link-open link arg - But in a temporal buffer, `org-link-abbrev-alist-local' is nil, and thus all abbreviations defined with #+LINK are lost. So a simple solution to this would be preserving the value of `org-link-abbrev-alist-local' when switching to the temporal buffer. I think this is orthogonal to the issue of the parser, and it's a bug on its own, since as a user I would expect that evaluating `org-link-open-from-string' would use my current buffer's local values of variables. What do you think? If you agree, I can send a patch fixing it in two lines with something like this: (let ((org-link-abbrev-alist (append org-link-abbrev-alist org-link-abbrev-alist-local))) (pcase (with-temp-buffer ...) ...)) or this: (let ((tmp-var (org-link-abbrev-alist-local))) (pcase (with-temp-buffer (setq org-link-abbrev-alist-local tmp-var) ...) ...)) P.S. There is another variable defined with `defvar-local' in ol.el: `org-target-link-regexp'. I don't know what it is used for but it could potentially suffer from the same problem.
[BUG] link abbreviations do not work inside property drawers [9.5.2 (release_9.5.2-38-g682ccd @ /home/ignacio/repos/emacs/lisp/org/)]
Hello, Link abbreviations do not work inside property drawers and are instead confused with internal links. The following org file illustrates this behavior. #+LINK: org-manual https://orgmode.org/manual/ * Heading :PROPERTIES: :myprop: [[org-manual:Hyperlinks.html]] :END: - Opening this link will move point to heading below * org-manual:Hyperlinks.html * Another Heading :PROPERTIES: :myprop: [[org-manual:Link-Abbreviations.html]] :END: - Opening this link will result in the following prompt: - No match: create this as a new heading? (yes or no) * Yet Another Heading [[org-manual:Link-Abbreviations.html]] - Opening this link will browse https://orgmode.org/manual/Link-Abbreviations.html, as it should I know that there is discussion of whether timestamps and links should work or not inside property drawers, but since they currently work, I think link abbreviations should be supported too. Let me know if you agree and I'll debug the issue and send a patch with a fix proposal. Regards, Ignacio Emacs : GNU Emacs 29.0.50 (build 44, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0) of 2022-04-23 Package: Org mode version 9.5.2 (release_9.5.2-38-g682ccd @ /home/ignacio/repos/emacs/lisp/org/)
Re: [BUG] org-agenda thinks timestamps after 23:00 correspond to the next day [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]
Max Nikulin writes: > On 05/04/2022 11:20, Kyle Meyer wrote: >> Max Nikulin writes: >> >>> Emacs copy of Org changed the way of calling `encode-time' as a result >>> interpretation of last nils returned by `org-parse-string' altered from >>> ignored to "no DST". >>> >> My suggestion: >>1. Send a report to bug-gnu-em...@gnu.org describing the issue. >> Ask >> that Paul revert those changes. >> I can do this at some point this week. > > Ignacio, have you tried recent emacs master branch? Paul reverted most > of his changed, see > > 8ef37913d Paul Eggert 2022-04-06 07:48:05 > Port Org encode-time usage back to Emacs 25 > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54731 > Yes, I have just tried, and everything works fine now. Thanks!
[BUG] (org-agenda-files) after restrict agenda to a file [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)]
Hello, After restricting the agenda to a file for a single agenda command, with 'C-c a < a', and exiting the agenda with 'x', (org-agenda-files) still returns that file instead of the original list of agenda files. This can be easily solved using the UNRESTRICTED optional argument in `org-agenda-files', but I wonder if this behavior is correct. The docstring of `org-agenda-files' says "Optional UNRESTRICTED means return the full list even if a restriction is currently in place." But as I understand it, the restriction is no longer in place, since it was only for the duration of the agenda command, as the Org Mode Manual says: "If you would like to focus the agenda temporarily on a file not in this list, or on just one file in the list, or even on only a subtree in a file, then this can be done in different ways. For a single agenda command, you may press ‘<’ once or several times in the dispatcher. To restrict the agenda scope for an extended period ..." *note This is probably a minor issue, but since it was the cause of a bug in my config that took me a while to debug, I'm reporting it in case you think that something should be done about it. In case you are curious about my use case, I was just doing something like (eval-after-load 'a-package '(setq org-agenda-files (append (org-agenda-files) (...))) Regards, Ignacio Emacs : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20) of 2022-01-16 Package: Org mode version 9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)
Re: [BUG] org-agenda thinks timestamps after 23:00 correspond to the next day [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]
> > Ubuntu-20.04 LTS has emacs-26.3, so... > > Could you, please, try > > (encode-time '(0 0 23 29 3 2022 nil -1 nil)) > ^^^ Thanks. Using -1 as DST argument indeed fixes it. However, while testing that, I've realized that I made a mistake in the bug report. `encode-time' and `org-parse-time-string' return the same both in old and current Emacs and org-mode versions (by old Emacs I mean Emacs 27, not 26). The problem is that in ELPA's org-mode, `org-time-string-to-time' is defined as (apply #'encode-time (org-parse-time-string s))) and in org-mode's built-in version of Emacs 29, it is defined as (encode-time (org-parse-time-string s))) and those two return different things. In the second case, the actual three last elements of the list returned by `org-parse-time-string' are used, and they are all nil. In the first case, according to the docstring of `encode-time', the last two elements of the list are ignored and -1 and nil are used as default. > If my guess is right, `org-parse-time-string' should add -1 instead of > nil in that position. So your guess is right, and doing this would restore the previous behavior. However, the curious things is that in the org-mode repository at git://git.savannah.gnu.org/emacs/org-mode.git, `org-time-string-to-time' still uses `apply', and always has. The change, and thus the bug, was only introduced directly in Emacs 29 a few months ago. So I guess this is an Emacs 29 bug? I didn't know the two repositories could diverge like that. Should I report it to Emacs 29 maintainers? Or can org-mode maintainers fix it in the Emacs repository?
Re: [BUG] org-agenda thinks timestamps after 23:00 correspond to the next day
> A first step to debug date issues is to check current timezone Thanks Max. > (getenv "TZ") This returns nil > $ timedatectl And this returns Local time: mié 2022-03-30 12:17:36 CEST Universal time: mié 2022-03-30 10:17:36 UTC RTC time: mié 2022-03-30 10:17:37 Time zone: Europe/Madrid (CEST, +0200) System clock synchronized: yes NTP service: active RTC in local TZ: no > I have not looked what changed in emacs in respect to timezones. The function `encode-time', which is implemented in C, has changed, since it returns different things in Emacs 27 and Emacs 29, when it receives as argument the return value of (org-parse-time-string ).
Re: [BUG] org-agenda thinks timestamps after 23:00 correspond to the next day [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]
Actually, this only happens with SCHEDULED timestamps, so it might be considered org-mode's fault since the handling of normal and SCHEDULED timestamps is not always consistent. The reason it is different is that `org-agenda-get-timestamps' looks for timestamps in the org buffer using a regular expression that already matches only the expected date. `org-agenda-get-scheduled' can't do that, so it uses a regular expression that matches any timestamp, converts the timestamp to an absolute date using `org-agenda--timestamp-to-absolute', and compares with the current agenda date. `org-agenda-get-timestamps' also has to do something similar for repeated tasks. However, the function used to get the absolute date is different for those timestamps. The function for scheduled timestamps boils down to (time-to-days (encode-time (org-parse-time-string timestamp))) but for repeating timestamps, it boils down to (calendar-absolute-from-gregorian (org-date-to-gregorian timestamp)) For the timestamp "<2022-03-30 mié 23:00>", the second form returns 738244 in my machine, which corresponds to (org-today) at 30/03/2022, but the second returns 738245. Thus, repeated timestamps still work, but scheduled timestamps don't. Is there a reason why two different ways to obtain those dates are used? For completion, I have also checked deadline timestamps, and they suffer from the same problem as scheduled timestamps. A deadline for today at 23:00 will appear in the agenda as it would a deadline for tomorrow at 22:59, that is, with a warning that it is due in one day, and not as a deadline for today at 22:59 would appear. Regards, Ignacio Ignacio Casso writes: > Hello, > > After last Saturday's hour change in Spain, org-agenda thinks that > timestamps after 23:00 correspond to the next day in Emacs 29. I'm not > actually sure if that is the reason, since I usually use Emacs 27, but I > guess it must be that if I have found out three days after the hour > change. > > I have tried to track down the problem, and it doesn't seem to be the > fault of any org-mode code change. The problem is that > (org-time-string-to-time timestamp), defined as (encode-time > (org-parse-time-string timestamp)), returns different things in Emacs 27 > and Emacs 29. > > Let's consider the timestamp "<2022-03-29 mar 23:00>" as an example: > > 1) (org-parse-time-string "<2022-03-29 mar 23:00>") returns (0 0 23 29 3 > 2022 nil nil nil). > > 2) (encode-time '(0 0 23 29 3 2022 nil nil nil)) returns '(25155 29520) > in Emacs 27, but (25155 33120) in Emacs 29 > > 3.1) (time-to-days '(25155 29520)) returns 738243 > > 3.2) (time-to-days '(25155 33120)) returns 738244 > > 4) (org-today) returns 738243 > > Therefore, org-agenda thinks that "<2022-03-29 mar 23:00>" is today in > Emacs 27, but tomorrow in Emacs 29. > > `encode-time' is defined in C, and is probably system dependent, so this > is probably not an org-mode bug. But maybe org-mode code could try to be > smart about this? I don't know if it's even possible. > > And if this should not be fixed in org-mode, do you know were it should? > It could be an Emacs bug? Or maybe the problem is in my system? > > Regards, > > --Ignacio > > > Emacs : GNU Emacs 29.0.50 (build 19, x86_64-pc-linux-gnu, GTK+ Version > 3.24.20, cairo version 1.16.0) > of 2022-03-29 > Package: Org mode version 9.5.2 (release_9.5.2-25-gaf6f12 @ > /home/ignacio/repos/emacs/lisp/org/)
[BUG] org-agenda thinks timestamps after 23:00 correspond to the next day [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]
Hello, After last Saturday's hour change in Spain, org-agenda thinks that timestamps after 23:00 correspond to the next day in Emacs 29. I'm not actually sure if that is the reason, since I usually use Emacs 27, but I guess it must be that if I have found out three days after the hour change. I have tried to track down the problem, and it doesn't seem to be the fault of any org-mode code change. The problem is that (org-time-string-to-time timestamp), defined as (encode-time (org-parse-time-string timestamp)), returns different things in Emacs 27 and Emacs 29. Let's consider the timestamp "<2022-03-29 mar 23:00>" as an example: 1) (org-parse-time-string "<2022-03-29 mar 23:00>") returns (0 0 23 29 3 2022 nil nil nil). 2) (encode-time '(0 0 23 29 3 2022 nil nil nil)) returns '(25155 29520) in Emacs 27, but (25155 33120) in Emacs 29 3.1) (time-to-days '(25155 29520)) returns 738243 3.2) (time-to-days '(25155 33120)) returns 738244 4) (org-today) returns 738243 Therefore, org-agenda thinks that "<2022-03-29 mar 23:00>" is today in Emacs 27, but tomorrow in Emacs 29. `encode-time' is defined in C, and is probably system dependent, so this is probably not an org-mode bug. But maybe org-mode code could try to be smart about this? I don't know if it's even possible. And if this should not be fixed in org-mode, do you know were it should? It could be an Emacs bug? Or maybe the problem is in my system? Regards, --Ignacio Emacs : GNU Emacs 29.0.50 (build 19, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0) of 2022-03-29 Package: Org mode version 9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)
[BUG] completion-at-point for [[* only works at end of line [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]
Hello, The manual says in https://orgmode.org/manual/Internal-Links.html#DOCF25 (footnote 25), that in-buffer completion can be used to insert links targeting a headline in current buffer. So a user can type [[* and C-M-i and all headlines in the buffer are offered for completion. However, that only works if [[* is the last thing in the line. If there is something after point in that line, it fails with the following message: cl--assertion-failed: Assertion failed: (<= start (point)), #, 242 Or if there are only whitespaces after point, with the following message instead: pcomplete-completions: Args out of range: "", 1, nil. Regards, --Ignacio Emacs : GNU Emacs 29.0.50 (build 18, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0) of 2022-03-26 Package: Org mode version 9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)
Re: [BUG] C-c C-o on headline evaluates source code blocks with links inside [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]
> The following patch should fix it: > > [4. patch --- text/x-diff; 0001-fixed-bug.patch] > From bc5092fdef512280b7d7d3aa04f1ba887360a759 Mon Sep 17 00:00:00 2001 > From: Ignacio > Date: Thu, 24 Mar 2022 01:15:44 +0100 > Subject: [PATCH] fixed bug > > --- > lisp/org/org.el | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/lisp/org/org.el b/lisp/org/org.el > index 67c8f1cedf..0fff28af81 100644 > --- a/lisp/org/org.el > +++ b/lisp/org/org.el > @@ -9063,7 +9063,8 @@ org-offer-links-in-entry >(org-back-to-heading t) >(setq end (save-excursion (outline-next-heading) (point))) >(while (re-search-forward org-link-any-re end t) > -(push (match-string 0) links)) > + (when (eq (org-element-type (org-element-context)) 'link) > + (push (match-string 0) links))) >(setq links (org-uniquify (reverse links > (cond > ((null links) Actually, this fix would suffer from the same problem as the fix for the issue of org-agenda recognizing timestamps inside source code blocks, and now links inside property drawers would no longer be opened using C-c C-o with point on the headline. So if we want to preserve that behavior the new lines should probably be (when (memq (org-element-type (org-element-context)) '(link node-property)) (push (match-string 0) links)) or something like that, with probably more element types in the list beside link and node-property.
[BUG] C-c C-o on headline evaluates source code blocks with links inside [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]
Hello, The recent threads about timestamps inside property drawers, which mentioned the issue of timestamps and links being recognized in contexts where they should not, had me experimenting a bit, and I found the following bug (point 3) which was probably introduced by some change regarding those issues: 1) `org-open-at-point' with point in a source code block calls and used to call `org-babel-open-src-block-result'. This is not documented on the docstring, but happens at least since Emacs 27' org built-in version, 9.4.4. 2) `org-open-at-point' with point in a link inside a source code block also calls `org-babel-open-src-block-result' since at least org version 9.4.4. However I think that back when I was using Emacs 26, with org-builtin version 9.1.9 or so, it opened the link. I think that when that was fixed, the bug in 3) was introduced. 3) `org-open-at-point' with point in a headline collects all org links in the body of the entry and offers to select one and open it, or if there was only one it opens it directly. Links are collected using a regular expression, so they match links inside a source code block. For the selected link, `org-open-at-point' moves the point to the link and calls itself recursively. In old versions of org, that means that it opened the link. But in new versions, that means it evaluates the source code block. To reproduce this behavior, just copy the following entry into an org buffer and type C-c C-o with point in the heading. It will evaluate the source code block, instead of just messaging "No Links" as it would do with a source code block without links. * Heading #+begin_src emacs-lisp (message "https://orgmode.org/manual/;) #+end_src The following patch should fix it: >From bc5092fdef512280b7d7d3aa04f1ba887360a759 Mon Sep 17 00:00:00 2001 From: Ignacio Date: Thu, 24 Mar 2022 01:15:44 +0100 Subject: [PATCH] fixed bug --- lisp/org/org.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/org/org.el b/lisp/org/org.el index 67c8f1cedf..0fff28af81 100644 --- a/lisp/org/org.el +++ b/lisp/org/org.el @@ -9063,7 +9063,8 @@ org-offer-links-in-entry (org-back-to-heading t) (setq end (save-excursion (outline-next-heading) (point))) (while (re-search-forward org-link-any-re end t) - (push (match-string 0) links)) + (when (eq (org-element-type (org-element-context)) 'link) + (push (match-string 0) links))) (setq links (org-uniquify (reverse links (cond ((null links) -- 2.25.1 Emacs : GNU Emacs 29.0.50 (build 15, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0) of 2022-03-23 Package: Org mode version 9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)
[BUG] org-complex-heading-regexp should consider COMMENT keywords [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]
Hello,
I think `org-complex-heading-regexp' and
`org-complex-heading-regexp-format' should consider COMMENT keywords, as
they do with TODO keywords, priorities, and tags.
Firstly, with things as they are, different methods for accessing the
headline text are inconsistent. For example, for the headline below,
(org-entry-get (point) "ITEM"), which uses `org-complex-heading-regexp',
returns "COMMENT My headline", while (org-element-property :title
(org-element-context)), which doesn't, returns "My headline".
*** TODO [#A] COMMENT My headline :my_tag:
But more importantly for me, this is a problem in particular with
org-capture, where I would like capture targets to be found regardless
of whether they are commented or not. But right now commented headlines
are only found if the COMMENT keyword also appears in the capture
template, and in that case if the headlines are later uncommented they
are no longer found. You can copy the entry below into an org file and
play around with it to reproduce this described behavior.
* COMMENT My Target
#+begin_src emacs-lisp
(let ((org-capture-templates
`(("d" "My capture template" entry
(file+headline ,buffer-file-name "My target")
"* My content"
:immediate-finish t
(org-capture nil "d"))
#+end_src
The cause of this is the use of `org-complex-heading-regexp-format' in
`org-capture-set-target-location'.
This is the bug I originally wanted to report, but after
exploring the cause I thought that the problem was really in
`org-complex-heading-regexp' and not org-capture's code.
What do you think? Do you know of any other uses of those variables and
how considering COMMENT keywords or not affects them?
If you agree I can send a patch that changes the default value of those
regexp variables. Otherwise, I can send a patch that just modifies the
code of `org-capture-set-target-location' to fix this only for the
org-capture use case.
Regards,
Ignacio
Emacs : GNU Emacs 29.0.50 (build 13, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
of 2022-03-21
Package: Org mode version 9.5.2 (release_9.5.2-25-gaf6f12 @
/home/ignacio/repos/emacs/lisp/org/)
Re: [BUG] Agenda no longer works for timestamps inside properties drawer [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]
>> What you see in the new Org version is not a bug. Property values are >> treated as plain text by Org. >> >> I was unable to find a place in manual describing that timestamps cannot >> be placed inside property values: >> I personally see allowing timestamps (and links) inside property values as a >> useful feature. >> Would it be of interest for other users? > > Yes, it's a quite useful feature. For years, via my Capture templates, I've > been adding a property named :Created: to the properties drawer as follows: > > :PROPERTIES: > :Created: <2022-03-06 Sun 22:42> > :END: > > Now, in 9.5.2, literally hundreds of entries that formerly appeared on the > built-in Agenda views cannot be easily found. It seems that I'm not the only one using this unintended feature in previous versions of org, and probably there will be many others who don't use the latest version of org and have not noticed yet but will have the same problem when they upgrade. I think that even if timestamps were never intended to be used inside property drawers before, the fact that it worked for a long time and nothing in the documentation suggested otherwise makes it a de facto feature, even if unintended, and should be preserved. I've located the line in org-agenda.el responsible of the new behavior, and the following patch seems to fix it. I suggest it is incorporated into the repository, maybe with a variable org-agenda-skip-timestamps-in-properties-drawer defaulting to t if not everyone agrees. >From 7a27ecd65aa6fea4240756d773c8efe8c4d506fd Mon Sep 17 00:00:00 2001 From: Ignacio Date: Tue, 22 Mar 2022 00:18:05 +0100 Subject: [PATCH] fixed --- lisp/org/org-agenda.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org/org-agenda.el b/lisp/org/org-agenda.el index ae0058e037..796b98201d 100644 --- a/lisp/org/org-agenda.el +++ b/lisp/org/org-agenda.el @@ -5732,7 +5732,7 @@ org-agenda-get-timestamps (org-before-first-heading-p) (and org-agenda-include-inactive-timestamps (org-at-clock-log-p)) -(not (eq 'timestamp (org-element-type (org-element-context) +(not (memq (org-element-type (org-element-context)) '(timestamp node-property (throw :skip nil)) (org-agenda-skip)) (let* ((pos (match-beginning 0)) -- 2.25.1
Re: [BUG] Resolving idle clocks needs multiple keystrokes [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]
> Hmm, I see the problem. I didn't think about that. > Thank you very much for your suggestion. But what about using > read-char-exclusive? It seems to have a timeout argument too, and > should apparently fix the issue (ie. the prompt will no longer > disappear at the first unintentional click). > > Romeo > That would indeed fix your bug, it seems. Not mine, since it does not reset the idle timer either. I suggest you reply https://lists.gnu.org/archive/html/emacs-orgmode/2022-02/msg00278.html with a patch, just replacing `read-char' with `read-char-exclusive'. --Ignacio
Re: [BUG] Resolving idle clocks needs multiple keystrokes [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]
> Hi, > > I don't know how closely it is related to your problem, but I've > reported another issue revolving around the use of read-char for the > prompt to resolve clocks. See > [[https://lists.gnu.org/archive/html/emacs-orgmode/2022-02/msg00278.html]]. > > Unfortunately I an not advanced enough in Elisp to know whether using > another function than read-char would solve your problem as well as > mine (maybe read-char-choice waits for a valid char, while resetting > the idle timer ?), but it might be a hint. What do you think ? The problem with `read-char-choice' is that it does not seem to have a timeout argument. `read-char' has, and `org-clock-resolve' uses it to update the prompt message with the current idle time every 45 seconds, calling (read-char ... 45) in a loop until it returns non-nil. With `read-char-choice' that would not be possible, and if `org-clock-idle-time' was N, after the N idle minutes, the prompt would appear saying something like "Emacs was idle for N minutes, what do you want to do?", but M minutes later the message would still be the same instead of replacing N with N+M. The patch I sent already fixes the bug I reported anyway. For yours, I suggest just wrapping `read-char' in `condition-case', unless someone knows of some other appropriate function.
Re: org-log-note-clock-out ends action after note, forgetting to clock in to something
"Tory S. Anderson" writes: > Ignacio Casso writes: > >>> Anyone else duplicating this error would be useful to know. >> >> I can't reproduce this bug in Emacs 27.2. > > This is good news: it means I can probably proceed with bisection and > debugging after updating to see if the issue persists. Thanks! > > I'm on orgmode 9.4.6, with emacs 28.0.50. On second though I realize I should have told you my org version, not Emacs. It's 9.5.2. And I have checked it in my org built-in version, 9.4.4, and there I can reproduce the bug, so it's not your configuration's fault and it was a bug that has already been fixed. I suggest you upgrade to a later org version to fix the issue.
[PATCH] Fix for bug that makes the user have to answer the prompt more than once for resolving running clock after being idle
Hello, I have fixed the bug reported in https://lists.gnu.org/archive/html/emacs-orgmode/2010-08/msg00188.html, https://lists.gnu.org/archive/html/emacs-orgmode/2019-02/msg00333.html, and https://lists.gnu.org/archive/html/emacs-orgmode/2022-03/msg00127.html. In the last of those threads (two emails) I explained in detail the bug and the reason it happens. Here is the patch: >From bb4c9e0836b039a496a033a002d97d7062bd8dc8 Mon Sep 17 00:00:00 2001 From: Ignacio Date: Thu, 17 Mar 2022 11:50:44 +0100 Subject: [PATCH] org-clock.el: resolve running clock after being idle only once * lisp/org-clock.el (org-resolve-clocks-if-idle): Cancel timer for `org-resolve-clocks-if-idle' while `org-clock-resolve' waits for the user to answer the prompt. After the user answered the prompt to resolve the running clock, the pending scheduled calls to `org-resolve-clocks-if-idle' (one for each minute it took the user to answer) were being executed immediately. But after an old change in Emacs, the user answer does not reset the idle timer anymore, so each of those calls thought that the user was still idle and prompted them again, to the user had to answer the same prompt again N times. This commit fixes that bug. TINYCHANGE --- lisp/org-clock.el | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/lisp/org-clock.el b/lisp/org-clock.el index 6f441c18e..83e6dd319 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -1231,7 +1231,9 @@ so long." (org-clock-user-idle-start (time-since org-clock-user-idle-seconds)) (org-clock-resolving-clocks-due-to-idleness t)) - (if (> org-clock-user-idle-seconds (* 60 org-clock-idle-time)) + (when (> org-clock-user-idle-seconds (* 60 org-clock-idle-time)) + (cancel-timer org-clock-idle-timer) + (setq org-clock-idle-timer nil) (org-clock-resolve (cons org-clock-marker org-clock-start-time) @@ -1240,7 +1242,10 @@ so long." (/ (float-time (time-since org-clock-user-idle-start)) 60))) - org-clock-user-idle-start) + org-clock-user-idle-start) + (when (and (org-clocking-p) (not org-clock-idle-timer)) +(setq org-clock-idle-timer + (run-with-timer 60 60 #'org-resolve-clocks-if-idle))) (defvar org-clock-current-task nil "Task currently clocked in.") (defvar org-clock-out-time nil) ; store the time of the last clock-out -- 2.25.1
Re: org-log-note-clock-out ends action after note, forgetting to clock in to something
> Anyone else duplicating this error would be useful to know. I can't reproduce this bug in Emacs 27.2. Please send some more information like your Emacs and Org versions and your org related configuration. See https://orgmode.org/manual/Feedback.html for an easy way to include this information automatically and some more useful guidelines about how to submit bug reports for org-mode. > Let me know if there is somewhere else I should report this issue. As far as I know this is the right place.
Re: [BUG] org-capture autoload bug? [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)]
> I'll write now the email to emacs-devel with all these issues and > mention in this thread the corresponding debbugs thread in case anyone > wants to follow it. 54...@debbugs.gnu.org
Re: [BUG] org-capture autoload bug? [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)]
>>> My recommendation would be to come up >>> with a non-org specific example which reproduces the behaviour and then >>> ask on emacs-devel, using the example to demonstrate the issue. >> >> I agree. I'm on it. After trying to build a simple example I have realized a part of my analysis was wrong. > Not really, all defcustoms have a :set attribute, be it passed > explicitly as a parameter or the default value, set-default. I was wrong about this: set-default is not the default setter for defcustoms without one, it's actually set-default-toplevel-value (although everywhere in the documentation and comments it says it is set-default). set-default-toplevel-value works well with let bindings, but set-default does not. > This issue happens with all autoload functions that use a custom > variable: if they are called inside a let form binding that variable > and the feature was not loaded yet, the let-binding will have no > effect. So this is only true for defcustoms without explicit :set argument if the let form is evaluated with lexical binding enabled. The following table shows all the cases and what works and doesn't: - Lexical Binding and no autoload for the variable -> The let binding is ignored in Emacs 27 (or more accurately, it's considered lexical), and an error occurs in Emacs 29 - Dynamic binding or autoload for the variable: - No setter (or the actual default, set-default-toplevel-value) -> Everything works as expected - Setter with set or set-default (the suggested value in the documentation) -> Everything breaks as discussed in previous emails So if we remove the setter for org-capture-templates, which is not actually needed as discussed, or use set-default-toplevel-value instead of set, it would fix the problem when dynamic binding is used, and in Emacs 29 it would at least produce an error with lexical binding. If an autoload cookie was also added, it would fix the problem also when lexical binding is used, but I understand that may come with its own disadvantages. I'll leave that decision to you, for me this is no longer a problem since I just require org-capture now before doing this. I'll write now the email to emacs-devel with all these issues and mention in this thread the corresponding debbugs thread in case anyone wants to follow it. Regards, Ignacio
Re: [BUG] org-capture autoload bug? [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)]
>>> For `defcustom' autoload generates no more than
>>>
>>> (defvar org-capture-templates nil "...")
>>>
>>> It seems, behavior depends on whether `org-capture-templates' has the :set
>>> attribute.
>> Not really, all defcustoms have a :set attribute, be it passed
>> explicitly as a parameter or the default value, set-default. This issue
>> happens with all autoload functions that use a custom variable: if they
>> are called inside a let form binding that variable and the feature was
>> not loaded yet, the let-binding will have no effect.
>
> To avoid misunderstanding. I was testing with Emacs-26.3 (Ubuntu-20.04
> focal LTS system package) and did not explicitly set lexical binding
> cookie in an .el file. However defcustom autoloading was assumed.
>
> ;; simulate effect of ;;;###autoload
> (defvar org-capture-templates nil)
>
> (defun print-org-capture-templates ()
> (message "print-org-capture-templates")
> (pp org-capture-templates)
> (message "-"))
> (let ((org-capture-templates
>'(("d" "default" entry
> (file "/tmp/capture-test.org")
> "* %?"
> (print-org-capture-templates)
> (require 'org-capture)
> (print-org-capture-templates))
>
> Second call of print-org-capture templates prints nil with original
> definition of `org-capture-templates' but it prints locally let-bound
> value if I comment out the :set attribute.
>
> I am not disputing any observation from your thorough study
> mid:paxpr06mb7760a3031924ba897fd082e4c6...@paxpr06mb7760.eurprd06.prod.outlook.com
> (it seems message delivery took several hours, so I noticed it after I
> sent my message).
Yes, I was wrong about that. Instead of testing it without :set
argument, I had tested it with a :set argument that was just
set-default plus some messages for debugging. I assumed that it was
equivalent since the documentation says that set-default is the default
value for :set. However it turns out that the actual default value that
is used when no argument is passed is set-default-toplevel-value. With
the later it works (with dynamic binding or autoload variable), but with
the former it doesn't. I think I tested once without :set argument, but
I must have used lexical binding so it didn't work anyway, so I
concluded that it didn't work either in that case.
Re: [BUG] org-capture autoload bug? [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)]
I've also investigated the issue a little bit further and wrote and email with my conclusions about the same time Max wrote his. I comment inline about a few of your thoughts: > For `defcustom' autoload generates no more than > > (defvar org-capture-templates nil "...") > > It seems, behavior depends on whether `org-capture-templates' has the :set > attribute. Not really, all defcustoms have a :set attribute, be it passed explicitly as a parameter or the default value, set-default. This issue happens with all autoload functions that use a custom variable: if they are called inside a let form binding that variable and the feature was not loaded yet, the let-binding will have no effect. > The setter receives nil instead of the let-bound value. I can not say > I understand the tricks with bypassing lexical binding in `defcustom' and some > checks in `custom-declare-variable'. Since emacs-26 something has changed: > I am unsure that the setter of `defcustom' should get let-bound value in the > case of autoloading since it might lead to fragile behavior. See my other email where I explain what I think that defcustom of a variable is doing when called inside a let-binding of that variable. >> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=6309131349 >>> - ;; Use defvar to set the docstring as well as the special-variable-p >>> flag. >>> - ;; FIXME: We should reproduce more of `defvar's behavior, such as the >>> warning >>> - ;; when the var is currently let-bound. >>> - (if (not (default-boundp symbol)) But the conclusion is that right now it does not work, so I think that warning is needed. > It looks like the setter on org-capture-template is used to do some > form of conversion on the template specification to force a new > format. Not sure how long that has been there or whether it is > actually still required. Could be that this setter was added to aid in > transition to a new template format which could/should be removed at > some point. That is right, it seems it was added for backwards compatibility when a new template format was added. However, it's not actually needed, since org-capture-select-template also calls that function to ensure they are in the new format. It needs to do so in order to allow setting org-capture-templates also with setq, or let-binding org-capture-templates as I do. That's not the problem anyway, as I explained above. > However, this behaviour seems like it may be the tip of a much bigger > issue outside of org-mode and potential source of bugs for Emacs. > Bottom line is I don't think any function should behave differently > depending on when autoload runs > Regardless, I don't think having the situation where the programmer must > know (guess) whether autoload will/could execute during the evaluation > of code they write is tenable and am beginning to suspect it may be an > Emacs bug OR a subtle bug in org-mode as a result to the transition to > lexical binding as the default. My recommendation would be to come up > with a non-org specific example which reproduces the behaviour and then > ask on emacs-devel, using the example to demonstrate the issue. I agree. I'm on it. >> Reading the code I noticed `org-capture-templates-contexts' so I wonder if it >> might help for the original use case. > > I thought about that as well. However, from re-reading the OP's posts, I > suspect not. org-capture-templates-contexts seems to be useful when you > want to restrict access to some templates based on context. However, > from reading the OP's posts, I get the impression that what they want is > for templates to be different based on context i.e. they still want the > template associated with 'd', but want its definition to be different. > > It is possible org-capture-template-contexts might provide an > alternative solution where you don't need to dynamically modify/add > templates in this manner. For example, you could have all your templates > defined, but only offer those relevant based on context. However, I > guess this would mean having to have different template keys, which > might be an issue. If I recall correctly template contexts allow to redefine the template key, so that would not be an issue. And yes, using template contexts could probably be a solution to my use case, as it would be having an org-capture version with template parameter. But don't worry too much about my use case, since a simple (require 'org-capture) is enough to keep doing what I was doing.
Re: [BUG] org-capture autoload bug? [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)]
> While I don't know if this is a bug, it certainly doesn't seem to be
> doing the right thing from an 'intuitive' point of view. I would expect
> when a variable is bound to a value inside a let and a function is then
> called which uses that variable, the initial let bound value should be
> used and the result be the same regardless of whether org-capture has or
> has not been loaded. It means there is a hidden side-effect here, which
> isn't good and probably needs more analysis. If you had set the value
> using setq rather than as a let form, it wouldn't be overridden when
> org-capture is loaded, so why does it when it is a let binding?
>
I've investigated this a little bit further and this is not specific to
org-capture. For example if you evaluate (let ((org-agenda-files
'("/tmp/foo.org"))) (org-agenda-list)) before org-agenda is laoded, the
let-binding of org-agenda-files is ignored too.
I think the reason is the following:
1) Loading the file defining those autoload functions runs defcustom for
the variable we are using.
2) defcustom calls the function F passed as argument with the :set
keyword (set-default by default) to initialize the variable. That
function receives as argument the variable and a value.
2.1) If the variable was already initialized (e.g., with setq) with a
value V, the value passed to F is V. It it was not, the value passed to
F is the value passed as STANDARD argument to defcustom. So far, so
good.
2.2) If the variable is let-bound with lexical-binding non-nil, there is
an error in Emacs 29, since at the time the variable is let-bound Emacs
does not know it is special and thus it uses lexical binding, but when
defcustom runs it finds out that it is special and therefore it should
have used dynamic binding. In Emacs 27 this check is not done, and the
let-binding is considered lexical, so it has no effect for uses of the
variable while the let body is being executed, unless they appear
textually within that body. In particular, the value passed to F is
again the STANDARD argument of defcustom.
2.2.1) An exception to this is when the variable is autoloaded, since
Emacs can know that it is special by the time is evaluates let.
2.2.2) But in general this means that the programmer should know whether
an autoload function is going to be loaded at that execution
point if he is going to do this.
2.3) If the variable is let-bound with lexical-binding nil, things then
break completely. First, the value passed to F is again the STANDARD
argument of defcustom. This makes sense since F would initialize the
variable globally and the let binding was supposed to be local. But it
means that again the let binding gets shadowed. But it's worse than
that. The initialization of the variable does not work and only has the
same scope as the let-binding, so after the let body is finished, the
variable is void. Furthermore, since the feature in question is already
provided, there is no easy way to leave that state and initialize the
variable again.
This makes me conclude that let-bindings of variables used by autoloaded
functions should be avoided unless we know for sure that the function
will be loaded at that point in execution.
> Might be worth asking a general question on emacs-devel? Stephan or Eli
> can probably provide some clarification here (maybe this is somehow
> related to the changes associated with the lexical binding stuff?)
Yes, I will email them explaining this, since I think the point 2.3 is a
bug. Maybe there is no better way to do this, but I think at least there
should be a warning if a misuse of let + autoload can leave Emacs in
what I think is a broken state.
Re: [BUG] Resolving idle clocks needs multiple keystrokes [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]
> So the problem is in (org-user-idle-seconds), which in my window system > boils down to a call to (current-idle-time). It should return 0 after > answering the prompt, but in my system it keeps counting up. At this > point I stopped investigating since that function is defined in C. > I have investigated this a little bit further and it seems that reading a character with read-char only resets the idle timer if the SECONDS argument is nil (which is not the case here) . I reported it as a bug to bug-gnu-em...@gnu.org, but it seems there is a reason for that. See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54371 > Since this bug is already old and I have not found much information > about it, I assume that in most systems answering the prompt does reset > the idle timer and this bug does not occur. It also seems to happen for all systems, so either much less people than I thought use this feature, or there is something else that makes this bug particular to my setup, although I can't think of anything else. > As a quick fix for those > systems where this is an issue, we could reset the idle timer ourselves > after the prompt in org-resolve-clocks-if-idle. I have thought of a better way to fix this, and currently there is no way to do reset the idle timer with Elisp anyway. I attach the patch: it just cancels the timer before prompting the user and sets it again if needed after the prompt is answered. What do you think? >From 288b25ea95699596762b199088ce6828a5e9a0ed Mon Sep 17 00:00:00 2001 From: Ignacio Date: Sun, 13 Mar 2022 21:41:43 +0100 Subject: [PATCH] fixed bug --- lisp/org/org-clock.el | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/lisp/org/org-clock.el b/lisp/org/org-clock.el index dce5d9d4c0..81d4a85782 100644 --- a/lisp/org/org-clock.el +++ b/lisp/org/org-clock.el @@ -1228,7 +1228,9 @@ org-resolve-clocks-if-idle (org-clock-user-idle-start (org-time-since org-clock-user-idle-seconds)) (org-clock-resolving-clocks-due-to-idleness t)) - (if (> org-clock-user-idle-seconds (* 60 org-clock-idle-time)) + (when (> org-clock-user-idle-seconds (* 60 org-clock-idle-time)) + (cancel-timer org-clock-idle-timer) + (setq org-clock-idle-timer nil) (org-clock-resolve (cons org-clock-marker org-clock-start-time) @@ -1237,7 +1239,10 @@ org-resolve-clocks-if-idle (/ (float-time (time-since org-clock-user-idle-start)) 60))) - org-clock-user-idle-start) + org-clock-user-idle-start) + (when (and (org-clocking-p) (not org-clock-idle-timer)) +(setq org-clock-idle-timer + (run-with-timer 60 60 #'org-resolve-clocks-if-idle))) (defvar org-clock-current-task nil "Task currently clocked in.") (defvar org-clock-out-time nil) ; store the time of the last clock-out -- 2.25.1
[BUG] Resolving idle clocks needs multiple keystrokes [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]
Hello, > CONTEXT: When I'm idling with the clock running, Org asks if I want > to resolve the clock when I come back (this is by setting > org-clock-idle-time). > > PROBLEM: I'm not sure how recent the change was, but Org started > asking me _multiple times_ what I want to do when back. I have this problem, already reported but not solved in these threads and maybe others: https://lists.gnu.org/archive/html/emacs-orgmode/2019-02/msg00333.html, https://lists.gnu.org/archive/html/emacs-orgmode/2010-08/msg00188.html. I have investigated a little and it seems that there is a timer that calls org-resolve-clocks-if-idle every minute, and if (org-user-idle-seconds) is greater than 60*org-clock-idle-time, that function prompts the user to resolve the clock. The problem is that this prompt blocks Emacs, and if you are idle (org-clock-idle-time + N) minutes, the other N scheduled calls to org-resolve-clocks-if-idle occur immediately after answering the prompt. But for some reason (a bug?), answering the prompt does not affect (org-user-idle-seconds), so the prompt appears again, and you have to answer it N times (unless your answer was to cancel the clock or clock out). So the problem is in (org-user-idle-seconds), which in my window system boils down to a call to (current-idle-time). It should return 0 after answering the prompt, but in my system it keeps counting up. At this point I stopped investigating since that function is defined in C. Since this bug is already old and I have not found much information about it, I assume that in most systems answering the prompt does reset the idle timer and this bug does not occur. As a quick fix for those systems where this is an issue, we could reset the idle timer ourselves after the prompt in org-resolve-clocks-if-idle. What do yo think? Emacs : GNU Emacs 29.0.50 (build 9, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0) of 2022-03-11 Package: Org mode version 9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)
[BUG] Agenda no longer works for timestamps inside properties drawer [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]
Hello, In Emacs 27.2, with an up to date version of org from ELPA (9.5.2), org-agenda considers timestamps that appear in property drawers, so the entry below appears in the daily agenda view. * Heading :PROPERTIES: :timestamp: <2022-03-12 sáb> :END: However, in the latest Emacs version built from source (29.0.50), with the built-in version of org (also 9.5.2, but the latest release, I assume), this is no longer the case and that entry does not appear in the agenda view. I know that maybe it's unorthodox, but I have some org files that rely in the previous behavior, with entries like the following: * Some friend :PROPERTIES: :birth-date: <1994-03-12 sáb +1y> :END: Is this a bug? If it's not, can someone point me to the functions I need to touch to restore the previous behavior? Or maybe I should stop doing this and start moving those timestamps out of the properties drawer in my files? Regards, Ignacio Emacs : GNU Emacs 29.0.50 (build 9, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0) of 2022-03-11 Package: Org mode version 9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)
Re: [BUG] org-capture autoload bug? [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)]
Max Nikulin writes:
> Ignacio, I think, you can add (require 'org-capture) inside your
> function just before `let' and it would work almost as lazy loading.
Thanks, I was already using (require 'org-capture) in my init file to
solve this. As I said, it's not really a problem for me, I was just
reporting it in case it was a bug. I was not sure since I don't really
know the inner workings of autoloads and custom variables, but since
this snippet works when org-capture is not yet loaded
(setq org-capture-templates
'(("d" "default" entry
(file+headline org-default-notes-file "Tasks")
"* %?")))
(org-capture nil "d")
and this snippet also works
(let ((my-new-var 2))
(defcustom my-new-var 1 "New variable that did not exist before")
(message "%s" my-new-var)) ;; This prints 2
(message "%s" my-new-var) ;; This prints 1
I thought that this snippet should work too when org-capture is not yet
loaded, and that the fact that it doesn't could mean that there is a bug
somewhere
(let ((org-capture-templates
'(("d" "default" entry
(file+headline org-default-notes-file "Tasks")
"* %?"
(org-capture nil "d")))
> I have no particular opinion concerning adding autoload cookie to
> `org-capture-templates'. Emacs has enough number of them, but Org has
> no such custom variables.
I put an autoload cookie myself and it doesn't fix it, so it's probably
not that. It's the first time I manage autoload cookies though, so I may
have done something wrong. I only tested that the autoload cookie worked
by checking that before loading org-capture, org-capture-templates
appears in the completion list for C-h v, and I can evaluate it.
Re: [BUG] org-capture autoload bug? [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)]
Max Nikulin writes:
> On 10/03/2022 19:53, Ignacio Casso wrote:
>> For example, if we call this:
>>(let ((org-capture-templates
>> '(("d" "default" entry
>> (file+headline org-default-notes-file "Tasks")
>> "* %?"
>> (org-capture nil "d")))
>> It produces the error:
>>(error "No capture template referred to by \"d\" keys")
>
> Ignacio, could you, please, try the following?
>
> (custom-set-variables
> '(org-capture-templates
>'(("d" "default" entry
> (file "/tmp/capture-test.org")
> "* %?"
> (org-capture nil "d")
>
That works, of course, but it's not suitable to my use case. The example
I have provided has been reduced from a larger function I wrote that
relies on org-capture functionality to create new entries in an org
file, using a template specific for that function which is not relevant
for any other Elisp code calling org-capture. Thus the function binds
locally and temporarily org-capture-templates, as I've seen other Elisp
code snippets do. If org-capture is already loaded it works just fine,
and I would expect it to work too when it is not and the function
triggers the autoload, but it doesn't.
[BUG] org-capture autoload bug? [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)]
Hello,
I think I've found a bug with org-capture autoload. If the first time
you use org-capture before it's actually loaded is within a let form binding
org-capture-templates, it produces an error saying that the template was
not found.
For example, if we call this:
(let ((org-capture-templates
'(("d" "default" entry
(file+headline org-default-notes-file "Tasks")
"* %?"
(org-capture nil "d")))
It produces the error:
(error "No capture template referred to by \"d\" keys")
Furthermore, depending on where that form was evaluated or defined, the
next time you called org-capture may work or produce the following
error:
org-capture: Symbol’s value as variable is void: org-capture-templates
In particular, if it is evaluated directly in the scratch buffer the
next call to org-capture works, and if it is part of a function
defined in my init file and evaluated in the scratch buffer, it produces
the error.
I have tried this too in Emacs 29 and the behaviour is similar, but
sometimes the error produced is
(error "Defining as dynamic an already lexical var")
instead of
(error "No capture template referred to by \"d\" keys")
This again depends on where the form is evaluated or defined.
Best regards,
Ignacio
P.S., I now this has an easy solution: not autoloading org-capture and having
(require 'org-capture) in my config. I'm just reporting the bug, if that
is what this is.
Emacs : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20)
of 2022-01-16
Package: Org mode version 9.5.2 (9.5.2-gfbff08 @
/home/ignacio/.emacs.d/elpa/org-9.5.2/)
[BUG] org-capture is not reentrant [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)]
Hello,
I recently tried to use (org-capture '(4) key) (i.e., C-u prefix
argument GOTO, so not actually capturing anything, just
moving to the target) as part of the function passed as target for
another capture template, using file+function, as in the example below:
(setq org-capture-templates
'(("i" "Inner" entry
(file+headline "/tmp/foo.org" "Target")
"* Wrong Heading"
:immediate-finish t)
("o" "Outer" entry
(file+function "/tmp/foo.org" capture-target) ;;
"* It works!!"
:immediate-finish t)))
(defun capture-target ()
(org-capture '(4) "i"))
(org-capture nil "o")
The result was:
* Target
** Wrong heading
So it worked for moving point to the desired target, but it overwrote
other parts of the template. I took a quick look at the code and it
seems that a global property list is used internally for the capture
process, which seems to be only initialized at the start of the capture
process and therefore the inner capture would overwrite it in our
case. I saw also that the global property list is copied to a buffer
local property list for the case of starting a new capture process
before typing C-c C-c in the indirect capture buffer.
Do you think it would be easy to recycle that code to also have a stack
of property lists and allow reentrancy? Would yo consider it useful? I
would, but not really worth it to implement unless it's a low hanging
fruit. If it is, I'd volunteer to do so (although my elisp-fu may be a
little bit lacking yet).
Regards,
Ignacio
Emacs : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20)
of 2022-01-16
Package: Org mode version 9.5.2 (9.5.2-gfbff08 @
/home/ignacio/.emacs.d/elpa/org-9.5.2/)
[BUG] Typo in manual [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)]
Hello, I would like to report a minor typo in the manual, although I'm not sure if this is the right place (please point me to it if it's not). In the section Appendix A Hacking -> Using the Mapping API (https://orgmode.org/manual/Using-the-Mapping-API.html), it says that org-map-entries returns an alist, but it actually returns a list (as correctly stated by C-h f org-map-entries). Regards, Ignacio Emacs : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20) of 2022-01-16 Package: Org mode version 9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)
[BUG] org-crypt: CRYPTKEY property does not work as expected [9.5.1 (9.5.1-g36086a @ /home/ignacio/.emacs.d/elpa/org-9.5.1/)]
Hello, I think I have found a bug in org-crypt, or that org-crypt documentation is not clear enough. The following configuration snippet in the org-crypt section of the org manual, as well as the docstring for org-crypt-key, suggest that a key value of nil can be used to specify symmetric encryption: (setq org-crypt-key nil) ;; GPG key to use for encryption ;; Either the Key ID or set to nil to use symmetric encryption. The same section of the manual, and again the docstring for org-crypt-key, suggest that the value of org-crypt-key can be overridden with the CRYPTKEY property. However, if I set in my configuration org-crypt-key to nil, to use symmetric encryption by default, and try to override it in a heading setting the CRYPTKEY property to one of my keys, it still uses symmetric encryption and prompts me for a password. And if I set in my configuration org-crypt-key to one of my keys, to use it by default, and try to override it in a heading setting the CRYPTKEY property to nil to use symmetric encryption, it still uses my key and does not prompt me for a password. In both cases, if I use as key value a string that does not match any key instead of nil (e.g, the empty string ""), which also means symmetric encryption if epa-file-encrypt-to is not set according to the docstring of org-crypt-key, everything works as expected. So maybe that is the only value that should be used to specify symmetric encryption when you want to combine it with asymmetric encryption depending of the file or entry, but if that is the case I think the documentation does not insist on that fact enough. It's true that the docstring for org-crypt-key does say "If this variable is nil, always use symmetric encryption, unconditionally.", and that "unconditionally" could be interpreted as even if a CRYPTKEY property has been set, but for me that is not clear enough and I only considered that interpretation after having this issue and debugging it for a while. To exhibit the behaviour exposed, the following simple org and init files and playing around with the value of org-crypt-key suffice: Org file: * Encrypted heading 1 :crypt: :PROPERTIES: :CRYPTKEY: :END: This text should be encrypted using , regardless of the value of org-crypt-key * Encrypted heading 2 :crypt: :PROPERTIES: :CRYPTKEY: nil :END: This text should be encrypted using symmetric encryption, regardless of the value of org-crypt-key Init file: (require 'package) (package-initialize) (require 'org) (require 'org-crypt) (org-crypt-use-before-save-magic) (add-to-list 'org-tags-exclude-from-inheritance "crypt") (customize-set-variable org-crypt-disable-auto-save t) (setq org-crypt-key nil) ;; (setq org-crypt-key "") Emacs : GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14) of 2020-03-26, modified by Debian Package: Org mode version 9.5.1 (9.5.1-g36086a @ /home/ignacio/.emacs.d/elpa/org-9.5.1/)
[BUG] Agenda display + blocked habits + org-agenda-dim-blocked-tasks set to 'invisible
Hello, I think I've found a bug in the agenda display when 'org-agenda-dim-blocked-tasks' is set to 'invisible', and there is a task that is a habit (i.e., 'STYLE' property set to 'habit') and is blocked (e.g., because 'org-enforce-todo-dependencies' is set to 't' or there is an 'ORDERED' property). In this scenario, the task does not appear in the agenda, but its consistency graph does appear, and not in a separate line, but appended to the end of the previous line, be it the previous task or the header line with the date. To reproduce the bug, only this minimal configuration and generating the agenda for this file is needed: (require 'org-habit) (customize-set-variable 'org-agenda-dim-blocked-tasks 'invisible) * Some habit :PROPERTIES: :ORDERED: t :END: ** TODO Habit 1 SCHEDULED: <2021-12-09 jue .+1d> :PROPERTIES: :STYLE: habit :END: ** TODO Habit 2 SCHEDULED: <2021-12-09 jue .+1d> :PROPERTIES: :STYLE: habit :END: Best regards, Ignacio Emacs : GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14) of 2020-03-26, modified by Debian Package: Org mode version 9.5 (9.5-g0a86ad @ /home/ignacio/.emacs.d/elpa/org-9.5/)
[BUG] Inconsistent behaviour of TODO + COMMENT + TODO dependencies + agenda? [9.5 (9.5-g0a86ad @ /home/ignacio/.emacs.d/elpa/org-9.5/)]
Hello, I'm not sure what is the expected behaviour of the COMMENT keyword for TODOs and the agenda, since I only found it in the "Exporting" section of the manual, but I find the following behaviour inconsistent: - Tasks with a COMMENT keyword or under a heading with a COMMENT keyword do not appear in the agenda. I'm not sure if this is a feature or just happens because there is a step involving exporting when the agenda is constructed, but it seems reasonable to me and I use the COMMENT keyword for this sometimes. - Tasks with a COMMENT keyword or under a heading with a COMMENT keyword DO matter when computing dependencies between tasks, when org-enforce-todo-dependencies is 't' or there is a 'ORDERED' property. These two points seem inconsistent to me, since the first leads me to believe that tasks under commented subtrees are as if they did not exist, but in the second we see that's not true. Am I interpreting the COMMENT keyword wrong? Best regards, Ignacio P.D: Just when I was going to send this I tried to investigate it a little bit more to not waste anyone's time, and I found the variable 'org-agenda-skip-comment-trees', which defaults to 't'. So now I see that if it is set to 'nil' it would not be inconsistent to me anymore, but I still think that the default behaviour is inconsistent, or at least unintituive for newcomers, and that maybe a corresponding variable like 'org-dependencies-skip-comment-trees' might be needed. Emacs : GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14) of 2020-03-26, modified by Debian Package: Org mode version 9.5 (9.5-g0a86ad @ /home/ignacio/.emacs.d/elpa/org-9.5/)
