Re: Repeating task hourly
On 29 July 2020 09:29, Gustavo Barros wrote: > But what will happen is that the task will be both "done" and "due" on > the same day. Which face shall org-habit use? Which symbol? > And that `org-habit-duration-to-days' performs its conversion of the > repeaters to days with `floor', I'd say it is pretty deliberate. Good catch, with sub-day intervals sr-days is always 0 so it's always overdue. A quick workaround is to change the floor to a ceiling and maybe flooring the month/year values manually, so it would only affect 3m+ and 4y+ habits by a day. > this was before the introduction of hourly repeaters, I'd take this to > be even more meaningful, not less. How do you figure?
Re: Repeating task hourly
On 29 July 2020 08:15, Gustavo Barros wrote: > Furthermore, considering the only thing org-habit does is to provide > the consistency graph for the task, and if this does not really work > for hourly repeaters, I still don't see the gain here. And there > would be other ways, in my view more appropriate ones, to separate > some tasks, if that's desired. IMHO, what you are proposing is just > eliminating an error message which was deliberately placed there by > the author, considering what org-habit is designed to do. But this is > just an user speaking, take this as a data point. The graph works for hourly repeaters in exactly the same way as it works in all other cases. It illustrates whether the task was done on a given day. The gain is being able to use org-habit at all with hourly repeating tasks. At the moment, this is unnecessarily precluded, and not even by the error I removed; the actual error that pops up if you build the agenda with an hourly habit is rather cryptic: if: Invalid duration string: .+5h As Kyle mentioned, I don't think authorial intent counts for a whole lot here since the code was last touched in 2009, years before hourly repeaters were added.
Re: Repeating task hourly
> Is there any way to do this or are the docs out of date?
I made a few quick changes to org-habit and it works prima facie. Will
continue testing for a bit.
>From e690d7b43143410d5d5af524bb1ff0819feebc24 Mon Sep 17 00:00:00 2001
From: nivekuil
Date: Mon, 27 Jul 2020 04:37:32 -0700
Subject: [PATCH] org-habit: allow hourly repeat
---
lisp/org-habit.el | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/lisp/org-habit.el b/lisp/org-habit.el
index f76f0f213..b9bb729c1 100644
--- a/lisp/org-habit.el
+++ b/lisp/org-habit.el
@@ -157,11 +157,12 @@ means of creating calendar-based reminders."
:group 'org-faces)
(defun org-habit-duration-to-days (ts)
- (if (string-match "\\([0-9]+\\)\\([dwmy]\\)" ts)
+ (if (string-match "\\([0-9]+\\)\\([hdwmy]\\)" ts)
;; lead time is specified.
(floor (* (string-to-number (match-string 1 ts))
(cdr (assoc (match-string 2 ts)
- '(("d" . 1)("w" . 7)
+ '(("h" . 0.041)
+ ("d" . 1)("w" . 7)
("m" . 30.4) ("y" . 365.25))
(error "Invalid duration string: %s" ts)))
@@ -199,9 +200,7 @@ This list represents a \"habit\" for the rest of this module."
(setq sr-days (org-habit-duration-to-days scheduled-repeat)
sr-type (progn (string-match "[\\.+]?\\+" scheduled-repeat)
(match-string-no-properties 0 scheduled-repeat)))
- (unless (> sr-days 0)
- (error "Habit %s scheduled repeat period is less than 1d" habit-entry))
- (when (string-match "/\\([0-9]+[dwmy]\\)" scheduled-repeat)
+ (when (string-match "/\\([0-9]+[hdwmy]\\)" scheduled-repeat)
(setq dr-days (org-habit-duration-to-days
(match-string-no-properties 1 scheduled-repeat)))
(if (<= dr-days sr-days)
--
2.27.0
Repeating task hourly
According to the manual at https://orgmode.org/manual/Repeated-tasks.html hourly repeating tasks are possible, but the code in org-habit.el seems to disagree, explicitly disallowing an interval <1d: (error "Habit %s scheduled repeat period is less than 1d" habit-entry)) Is there any way to do this or are the docs out of date?
Re: nondeterministic org-test-with-temp-text?
On 3 June 2020 15:26, Nicolas Goaziou wrote: > You only need the last `org-id-goto' call right? Is the call to this > function meaningful, or can point be left at the beginning of "A1" > headline instead? Yes, I should have mentioned that you need to start in overview view. The idea is to selectively reveal only two subtrees, leaving the middle A2 hidden.
Re: nondeterministic org-test-with-temp-text?
On 31 May 2020 04:09, Nicolas Goaziou wrote: > I just fixed it, IIUC. Thank you. It works indeed. However, I believe I have found another bug :) Try these commands with the following org file; it appears to fail to land on a heading: (org-id-goto "105dfe8b-8507-400c-862f-a25882448051") (org-id-goto "4a3206fc-b2f1-47d6-9876-ea30c24ecbeb") (org-cycle) (org-next-visible-heading) (org-next-previous-heading) * A ** A1 :PROPERTIES: :ID: 4a3206fc-b2f1-47d6-9876-ea30c24ecbeb :END: blah ** A2 :PROPERTIES: :ID: 60dbdfd7-04a6-4ef0-86ce-a267c16fb1e9 :END: blah ** A3 :PROPERTIES: :ID: 105dfe8b-8507-400c-862f-a25882448051 :END: blah * B
Re: nondeterministic org-test-with-temp-text?
On 3 June 2020 09:27, Kevin Liu wrote: > (org-next-previous-heading) Typo; this should be (org-previous-visible-heading)
Re: [PATCH] Fix org-narrow-to-subtree smaller than subtree
> There is a good reason for this. If you insert text at (point-max), you > break the following headline. > > OTOH `org-mark-element' should pay attention to buffer boundaries. Good point. `org-mark-element` uses (org-element-property); I wonder if it makes sense to have the actual :end property of a subtree be the same as its narrowed boundary?
Re: nondeterministic org-test-with-temp-text?
On 30 May 2020 09:09, Nicolas Goaziou wrote: > You cannot call `org-cycle' consecutively without care, because it > checks `last-command' and `this-command'. You need to fake their values > before calling `org-cycle' again. Good to know, thanks. Relatedly, would you be willing to take a look at the bug at hand with (org-next-visible-headline)? I think the recent rewrite has changed its behavior in a way outlined by my test cases. Specifically, not always landing on a headline will break speed keys.
nondeterministic org-test-with-temp-text?
I’m trying to add a test (which should fail at the moment, representing an org-mode bug), but it seems like each ‘should’ form is actually nondeterministic. The first form returns nil on the first eval and t on subsequent evals, its behavior resetting upon any command, and the second form does the inverse, returning t on the first eval and nil on subsequent evals. Is this behavior expected? (ert-deftest test-org/org-next-visible-heading () (should (org-test-with-temp-text "* A\n** B\n\n\n* C" (org-overview) (org-cycle) (org-cycle) (org-next-visible-heading 1) (and (bolp) (org-at-heading-p (should (org-test-with-temp-text "* A\n** B\n\n\n* C" (org-overview) (org-cycle) (org-cycle) (org-cycle) (org-next-visible-heading 1) (and (bolp) (org-at-heading-p)
Re: [PATCH] Fix org-narrow-to-subtree smaller than subtree
Oh, of course I attached the wrong patch again. Wish mu4e-compose could preview these. >From 5f7cf68f92d3fa82d01646f7f1e12a4d18bad2fb Mon Sep 17 00:00:00 2001 From: nivekuil Date: Sat, 30 May 2020 00:11:19 -0700 Subject: [PATCH] Make narrowed subtree same size as the subtree, not 1 char less Right now a narrowed subtree is one char smaller than the actual subtree. (org-mark-element) on a narrowed subtree will select a region 1 char out of bounds, for example. There doesn't seem like a good reason for this to be the case. * lisp/org.el (org-toggle-narrow-to-subtree): Just use (org-end-of-subtree) as the end of the subtree. * testing/lisp/test-ob.el (test-ob/parse-header-args2): Since we're no longer subtracting the narrowed subtree size by 1, the subtree text here is now 1 character longer. I think this is reasonable and shouldn't be surprising enough to ruin anyone's day. If it isn't, then (org-end-of-subtree) should be changed rather than org-narrow-to-subtree. * testing/lisp/test-org-datetree.el (test-org-datetree/find-date-create): (test-org-datetree/find-iso-week-create): No more double newlines between months in datetree, but this just seems like incidental behavior more than deliberate behavior to begin with. --- lisp/org.el | 4 +--- testing/lisp/test-ob.el | 2 +- testing/lisp/test-org-datetree.el | 4 ++-- 3 files changed, 4 insertions(+), 6 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 0808fc210..f69919b20 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -7748,9 +7748,7 @@ If yes, remember the marker and the distance to BEG." (org-with-limited-levels (narrow-to-region (progn (org-back-to-heading t) (point)) - (progn (org-end-of-subtree t t) - (when (and (org-at-heading-p) (not (eobp))) (backward-char 1)) - (point))) + (progn (org-end-of-subtree t t) (point))) (defun org-toggle-narrow-to-subtree () "Narrow to the subtree at point or widen a narrowed buffer." diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el index 7c44622ef..2a2a66952 100644 --- a/testing/lisp/test-ob.el +++ b/testing/lisp/test-ob.el @@ -233,7 +233,7 @@ this is simple" (should (string-match (regexp-quote "this is simple") (org-babel-ref-resolve "simple-subtree"))) (org-babel-next-src-block) -(should (= 14 (org-babel-execute-src-block) +(should (= 15 (org-babel-execute-src-block) (ert-deftest test-ob/inline-src-blocks () (should diff --git a/testing/lisp/test-org-datetree.el b/testing/lisp/test-org-datetree.el index 5557d5e23..f7247766a 100644 --- a/testing/lisp/test-org-datetree.el +++ b/testing/lisp/test-org-datetree.el @@ -58,7 +58,7 @@ ;; Sort new entry in right place. (should (string-match -"\\`\\* 2012\n\\*\\* 2012-02 .*\n\\*\\*\\* 2012-02-01 .*\n\n\\*\\* 2012-03 .*\n\\*\\*\\* 2012-03-29 .*\\'" +"\\`\\* 2012\n\\*\\* 2012-02 .*\n\\*\\*\\* 2012-02-01 .*\n\\*\\* 2012-03 .*\n\\*\\*\\* 2012-03-29 .*\\'" (org-test-with-temp-text "* 2012\n** 2012-03 month\n*** 2012-03-29 day" (let ((org-datetree-add-timestamp nil)) (org-datetree-find-date-create '(3 29 2012)) @@ -161,7 +161,7 @@ ;; Sort new entry in right place. (should (string-match -"\\`\\* 2015\n\\*\\* 2015-W01\n\\*\\*\\* 2014-12-31 .*\n\n\\*\\* 2015-W36\n\\*\\*\\* 2015-09-01 .*\\'" +"\\`\\* 2015\n\\*\\* 2015-W01\n\\*\\*\\* 2014-12-31 .*\n\\*\\* 2015-W36\n\\*\\*\\* 2015-09-01 .*\\'" (org-test-with-temp-text "* 2015" (let ((org-datetree-add-timestamp nil)) (org-datetree-find-iso-week-create '(9 1 2015)) -- 2.26.2
[PATCH] Fix org-narrow-to-subtree smaller than subtree
I noticed that when I narrow to a subtree and then hit org-mark-element, I can’t kill the text because the narrow is actually 1 char smaller. This seemed like an unpleasant workaround, and I think the behavior can be changed without any real negative consequences. >From 61260469a9ad37ad4011cc489dc4372b02491b4d Mon Sep 17 00:00:00 2001 From: nivekuil Date: Tue, 26 May 2020 23:17:43 -0700 Subject: [PATCH] Narrow to whole subtree instead of 1 char less --- lisp/org.el | 1 - testing/lisp/test-org-datetree.el | 4 ++-- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 0808fc210..e9771512d 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -7749,7 +7749,6 @@ If yes, remember the marker and the distance to BEG." (narrow-to-region (progn (org-back-to-heading t) (point)) (progn (org-end-of-subtree t t) - (when (and (org-at-heading-p) (not (eobp))) (backward-char 1)) (point))) (defun org-toggle-narrow-to-subtree () diff --git a/testing/lisp/test-org-datetree.el b/testing/lisp/test-org-datetree.el index 5557d5e23..f7247766a 100644 --- a/testing/lisp/test-org-datetree.el +++ b/testing/lisp/test-org-datetree.el @@ -58,7 +58,7 @@ ;; Sort new entry in right place. (should (string-match -"\\`\\* 2012\n\\*\\* 2012-02 .*\n\\*\\*\\* 2012-02-01 .*\n\n\\*\\* 2012-03 .*\n\\*\\*\\* 2012-03-29 .*\\'" +"\\`\\* 2012\n\\*\\* 2012-02 .*\n\\*\\*\\* 2012-02-01 .*\n\\*\\* 2012-03 .*\n\\*\\*\\* 2012-03-29 .*\\'" (org-test-with-temp-text "* 2012\n** 2012-03 month\n*** 2012-03-29 day" (let ((org-datetree-add-timestamp nil)) (org-datetree-find-date-create '(3 29 2012)) @@ -161,7 +161,7 @@ ;; Sort new entry in right place. (should (string-match -"\\`\\* 2015\n\\*\\* 2015-W01\n\\*\\*\\* 2014-12-31 .*\n\n\\*\\* 2015-W36\n\\*\\*\\* 2015-09-01 .*\\'" +"\\`\\* 2015\n\\*\\* 2015-W01\n\\*\\*\\* 2014-12-31 .*\n\\*\\* 2015-W36\n\\*\\*\\* 2015-09-01 .*\\'" (org-test-with-temp-text "* 2015" (let ((org-datetree-add-timestamp nil)) (org-datetree-find-iso-week-create '(9 1 2015)) -- 2.26.2
Re: [PATCH] Fix org-capture-place-entry narrow bounds
Sorry, corrected patch format: >From 8e7b28054492424170f14f11297b416ef7575540 Mon Sep 17 00:00:00 2001 From: nivekuil Date: Fri, 29 May 2020 16:48:31 -0700 Subject: [PATCH] capture: Fix org-capture-place-entry narrow bounds * lisp/org-capture.el (org-capture-place-entry): Prevent breaking the following headline inside the capture buffer. This should match the behavior from 9.3. (org-capture-finalize): Reverts cb2774d1a, which solves a similar problem but only in the finalize stage, so the subtree structure would still be broken in the middle of editing the capture. --- lisp/org-capture.el | 12 +--- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/lisp/org-capture.el b/lisp/org-capture.el index 9136d331b..4d2c3e8d4 100644 --- a/lisp/org-capture.el +++ b/lisp/org-capture.el @@ -728,16 +728,6 @@ captured item after finalizing." (run-hooks 'org-capture-prepare-finalize-hook) - ;; Fix missing final newline, as it may have been deleted by accident - (when (eq (org-capture-get :type 'local) 'entry) -(save-excursion - (goto-char (point-max)) - (and (not (looking-at-p "^")) - (org-with-wide-buffer - (and (not (looking-at-p org-heading-regexp)) - (not (eobp - (insert "\n" - ;; Did we start the clock in this capture buffer? (when (and org-capture-clock-was-started org-clock-marker @@ -1166,7 +1156,7 @@ may have been stored before." (org-capture-empty-lines-after) (unless (org-at-heading-p) (outline-next-heading)) (org-capture-mark-kill-region origin (point)) - (org-capture-narrow beg (point)) + (org-capture-narrow beg (if (eobp) (point) (1- (point (org-capture--position-cursor beg (point)) (defun org-capture-place-item () -- 2.26.2 On 29 May 2020 17:25, Kevin Liu wrote: > This is a patch to fix my previous report of a regression in capture > behavior between 9.3 and 9.3.6: > >> Basically, the last position in the narrowed org-capture is actually >> the first position on the next line, so when you go to (end-of-buffer) >> and start typing you start clobbering the next headline. > > The fix already landed in cb2774d1a is inadequate for me as the subtree > structure can still be broken during the capture process. I think this > is the more correct approach, though I haven't done much testing outside > of my own workflow and `make test`. It seems to be the same behavior as > 9.3. > > From e6f4faacd2db9ea3f5dc6d6582e0e58ee11c8bef Mon Sep 17 00:00:00 2001 > From: nivekuil > Date: Fri, 29 May 2020 16:48:31 -0700 > Subject: [PATCH] Fix org-capture-narrow > > --- > lisp/org-capture.el | 12 +--- > 1 file changed, 1 insertion(+), 11 deletions(-) > > diff --git a/lisp/org-capture.el b/lisp/org-capture.el > index 9136d331b..4d2c3e8d4 100644 > --- a/lisp/org-capture.el > +++ b/lisp/org-capture.el > @@ -728,16 +728,6 @@ captured item after finalizing." > >(run-hooks 'org-capture-prepare-finalize-hook) > > - ;; Fix missing final newline, as it may have been deleted by accident > - (when (eq (org-capture-get :type 'local) 'entry) > -(save-excursion > - (goto-char (point-max)) > - (and (not (looking-at-p "^")) > -(org-with-wide-buffer > - (and (not (looking-at-p org-heading-regexp)) > - (not (eobp > -(insert "\n" > - >;; Did we start the clock in this capture buffer? >(when (and org-capture-clock-was-started >org-clock-marker > @@ -1166,7 +1156,7 @@ may have been stored before." > (org-capture-empty-lines-after) > (unless (org-at-heading-p) (outline-next-heading)) > (org-capture-mark-kill-region origin (point)) > - (org-capture-narrow beg (point)) > + (org-capture-narrow beg (if (eobp) (point) (1- (point > (org-capture--position-cursor beg (point)) > > (defun org-capture-place-item ()
[PATCH] Fix org-capture-place-entry narrow bounds
This is a patch to fix my previous report of a regression in capture behavior between 9.3 and 9.3.6: > Basically, the last position in the narrowed org-capture is actually > the first position on the next line, so when you go to (end-of-buffer) > and start typing you start clobbering the next headline. The fix already landed in cb2774d1a is inadequate for me as the subtree structure can still be broken during the capture process. I think this is the more correct approach, though I haven't done much testing outside of my own workflow and `make test`. It seems to be the same behavior as 9.3. >From e6f4faacd2db9ea3f5dc6d6582e0e58ee11c8bef Mon Sep 17 00:00:00 2001 From: nivekuil Date: Fri, 29 May 2020 16:48:31 -0700 Subject: [PATCH] Fix org-capture-narrow --- lisp/org-capture.el | 12 +--- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/lisp/org-capture.el b/lisp/org-capture.el index 9136d331b..4d2c3e8d4 100644 --- a/lisp/org-capture.el +++ b/lisp/org-capture.el @@ -728,16 +728,6 @@ captured item after finalizing." (run-hooks 'org-capture-prepare-finalize-hook) - ;; Fix missing final newline, as it may have been deleted by accident - (when (eq (org-capture-get :type 'local) 'entry) -(save-excursion - (goto-char (point-max)) - (and (not (looking-at-p "^")) - (org-with-wide-buffer - (and (not (looking-at-p org-heading-regexp)) - (not (eobp - (insert "\n" - ;; Did we start the clock in this capture buffer? (when (and org-capture-clock-was-started org-clock-marker @@ -1166,7 +1156,7 @@ may have been stored before." (org-capture-empty-lines-after) (unless (org-at-heading-p) (outline-next-heading)) (org-capture-mark-kill-region origin (point)) - (org-capture-narrow beg (point)) + (org-capture-narrow beg (if (eobp) (point) (1- (point (org-capture--position-cursor beg (point)) (defun org-capture-place-item () -- 2.26.2
Re: Regression from 9.3 to 9.3.6: newlines getting swallowed on org-capture
Thanks, it does indeed seem to be fixed on master. On 27 May 2020 18:23, Kyle Meyer wrote: > Kevin Liu writes: > >> Basically, the last position in the narrowed org-capture is actually >> the first position on the next line, so when you go to (end-of-buffer) >> and start typing you start clobbering the next headline. >> >> I tested this with emacs -Q, capturing an `entry` with `file+headline` >> in org 9.3 and it was working as expected, then in that same session >> loaded 9.3.6 and the capture buffer was one character longer (the >> added newline at the end) enabling the clobbering behavior. > > I believe Bastien fixed this in cb2774d1a (org-capture.el: Fix possibly > missing final newline, 2020-02-18).
Regression from 9.3 to 9.3.6: newlines getting swallowed on org-capture
This old thread describes similar behavior: https://emacs.stackexchange.com/questions/37097/newlines-swallowed-by-org-capture Basically, the last position in the narrowed org-capture is actually the first position on the next line, so when you go to (end-of-buffer) and start typing you start clobbering the next headline. I tested this with emacs -Q, capturing an `entry` with `file+headline` in org 9.3 and it was working as expected, then in that same session loaded 9.3.6 and the capture buffer was one character longer (the added newline at the end) enabling the clobbering behavior.
Bug: org-agenda-finalize throws args-out-of-range [9.3.6 (9.3.6-19-gf360f9-elpaplus @ /home/nivekuil/.emacs.d/elpa/org-plus-contrib-20200302/)]
This bit in org-agenda-finalize: (save-excursion (while (org-activate-links (point-max)) (add-text-properties (match-beginning 0) (match-end 0) '(face org-link Will throw an error at add-text-properties: Debugger entered--Lisp error: (args-out-of-range 0 2) add-text-properties(0 2 (face org-link)) org-agenda-finalize() org-agenda-list(nil) funcall-interactively(org-agenda-list nil) call-interactively(org-agenda-list) org-agenda(nil) funcall-interactively(org-agenda nil) call-interactively(org-agenda nil nil) command-execute(org-agenda) This happens after I open the agenda, C-c C-o a captured file from my org-journal, and then open the agenda again. The effect is that subsequent links after the first are not styled (visible brackets, not a link). However, it seems like add-text-properties may be redundant, and org-activate-links does it already? I deleted the add-text-properties sexp entirely and it seems to work as expected. Emacs : GNU Emacs 27.0.60 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.14, cairo version 1.17.3) of 2020-02-24 Package: Org mode version 9.3.6 (9.3.6-19-gf360f9-elpaplus @ /home/nivekuil/.emacs.d/elpa/org-plus-contrib-20200302/)
