I configured my org-todo-keywords in a way, that they are just single unicode symbols instead of the classic TODO, NEXT, WAIT, DONE,etc. This is done in my init.el like this: (setq org-todo-keywords '((sequence "⭕(p)" "⸰(t)" "▶(n)" "⏸(w)" "|" "✔(d)" "❌(c)" "⏩(r)"))) This works perfectly, so I can advance the todo-states, choose them directly, and filter on them in the agenda's todo-view, even org-edna, which heavily relies on them works as designed. While trying to use GTDs approach I defined a stuck project as one having no next action meaning, having no subheading with a todo state of "▶" (setq org-stuck-projects '("project" ("▶" "NEXT") nil "")) The 'NEXT' is used here only for validating the existence of a bug, originally it was omitted in my config. My projects look like this: ** ⭕ [3/4] Dame Edna :project:dame:... ** ⭕ [0/13] Example project: Garage Project :project:garage: :PROPERTIES: :COLUMNS: %40ITEM %8Effort(Effort){:} %60BLOCKER :COOKIE_DATA: todo recursive :END: *** ⸰ Find local stores for paint *** ⸰ Choose color for paint *** ⸰ Buy paint *** ⸰ Move car to nearby parking lot *** ⸰ Remove bikes *** ⸰ Remove stuff from shelves *** ⸰ Remove shelves *** ▶ Garage is empty *** ⸰ Paint walls and floor *** ⸰ Re-install shelves *** ⸰ Bring back bikes into garage *** ⸰ Bring back car into garage *** ⸰ Celebrate and close project Both of them contain a subheading with a todo state of "▶" which should prevent them from showing up in the stuck projects agenda view. However, they both appear List of stuck projects: ops: ⭕ [3/4] Dame Edna :project:dame: ops: ⭕ [0/13] Example project: Garage Project :project:garage: I suspected the problem to be with the excluded todo-state beeing a unicode symbol, so I tried to substitute it with the classical 'NEXT', so it now showed like this: ** ⭕ [3/4] Dame Edna :project:dame: ** ⭕ [0/13] Example project: Garage Project :project:garage: :PROPERTIES: :COLUMNS: %40ITEM %8Effort(Effort){:} %60BLOCKER :COOKIE_DATA: todo recursive :END: *** ⸰ Find local stores for paint *** ⸰ Choose color for paint *** ⸰ Buy paint *** ⸰ Move car to nearby parking lot *** ⸰ Remove bikes *** ⸰ Remove stuff from shelves *** ⸰ Remove shelves *** NEXT Garage is empty *** ⸰ Paint walls and floor *** ⸰ Re-install shelves *** ⸰ Bring back bikes into garage *** ⸰ Bring back car into garage *** ⸰ Celebrate and close project And now the Garage project is successfully removed from the stuck projects, because it contains a NEXT at the position of the todo keyword, despite the fact, that NEXT is not even defined as a valid todo keyword. Looks like in this place there is some simple string comparison magic happening, that can't handle unicode, instead of usage of the defined org-todo-keywords ------------------------------------------------------------------------ Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 2.24.32) of 2020-08-12 Package: Org mode version 9.3.6 (9.3.6-4-gdfa7a3-elpa @ /home/andy/.config/emacs/elpa/org-20200217/) current state: ============== (setq org-todo-keywords '((sequence "⭕(p)" "⸰(t)" "▶(n)" "⏸(w)" "|" "✔(d)" "❌(c)" "⏩(r)") ) org-stuck-projects '("project" ("▶" "NEXT") nil "") org-use-property-inheritance t org-tags-exclude-from-inheritance '("crypt" "project") org-agenda-files '("~/cloud/org/ops.org") org-closed-keep-when-no-todo t )
I configured my org-todo-keywords in a way, that they are just single unicode symbols instead of the classic TODO, NEXT, WAIT, DONE,etc. This is done in my init.el like this: (setq org-todo-keywords '((sequence "⭕(p)" "⸰(t)" "▶(n)" "⏸(w)" "|" "✔(d)" "❌(c)" "⏩(r)"))) This works perfectly, so I can advance the todo-states, choose them directly, and filter on them in the agenda's todo-view, even org-edna, which heavily relies on them works as designed. While trying to use GTDs approach I defined a stuck project as one having no next action meaning, having no subheading with a todo state of "▶" (setq org-stuck-projects '("project" ("▶" "NEXT") nil "")) The 'NEXT' is used here only for validating the existence of a bug, originally it was omitted in my config. My projects look like this: ** ⭕ [3/4] Dame Edna :project:dame:... ** ⭕ [0/13] Example project: Garage Project :project:garage: :PROPERTIES: :COLUMNS: %40ITEM %8Effort(Effort){:} %60BLOCKER :COOKIE_DATA: todo recursive :END: *** ⸰ Find local stores for paint *** ⸰ Choose color for paint *** ⸰ Buy paint *** ⸰ Move car to nearby parking lot *** ⸰ Remove bikes *** ⸰ Remove stuff from shelves *** ⸰ Remove shelves *** ▶ Garage is empty *** ⸰ Paint walls and floor *** ⸰ Re-install shelves *** ⸰ Bring back bikes into garage *** ⸰ Bring back car into garage *** ⸰ Celebrate and close project Both of them contain a subheading with a todo state of "▶" which should prevent them from showing up in the stuck projects agenda view. However, they both appear List of stuck projects: ops: ⭕ [3/4] Dame Edna :project:dame: ops: ⭕ [0/13] Example project: Garage Project :project:garage: I suspected the problem to be with the excluded todo-state beeing a unicode symbol, so I tried to substitute it with the classical 'NEXT', so it now showed like this: ** ⭕ [3/4] Dame Edna :project:dame: ** ⭕ [0/13] Example project: Garage Project :project:garage: :PROPERTIES: :COLUMNS: %40ITEM %8Effort(Effort){:} %60BLOCKER :COOKIE_DATA: todo recursive :END: *** ⸰ Find local stores for paint *** ⸰ Choose color for paint *** ⸰ Buy paint *** ⸰ Move car to nearby parking lot *** ⸰ Remove bikes *** ⸰ Remove stuff from shelves *** ⸰ Remove shelves *** NEXT Garage is empty *** ⸰ Paint walls and floor *** ⸰ Re-install shelves *** ⸰ Bring back bikes into garage *** ⸰ Bring back car into garage *** ⸰ Celebrate and close project And now the Garage project is successfully removed from the stuck projects, because it contains a NEXT at the position of the todo keyword, despite the fact, that NEXT is not even defined as a valid todo keyword. Looks like in this place there is some simple string comparison magic happening, that can't handle unicode, instead of usage of the defined org-todo-keywords ------------------------------------------------------------------------ Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 2.24.32) of 2020-08-12 Package: Org mode version 9.3.6 (9.3.6-4-gdfa7a3-elpa @ /home/andy/.config/emacs/elpa/org-20200217/) current state: ============== (setq org-todo-keywords '((sequence "⭕(p)" "⸰(t)" "▶(n)" "⏸(w)" "|" "✔(d)" "❌(c)" "⏩(r)") ) org-stuck-projects '("project" ("▶" "NEXT") nil "") org-use-property-inheritance t org-tags-exclude-from-inheritance '("crypt" "project") org-agenda-files '("~/cloud/org/ops.org") org-closed-keep-when-no-todo t ) Andy Drop
Hi Andreas,
Andreas Drop <drops@mailbox.org> writes:
> I configured my org-todo-keywords in a way, that they are just single
> unicode symbols instead of the classic TODO, NEXT, WAIT, DONE,etc. This is
> done in my init.el like this:
>
> (setq org-todo-keywords '((sequence "⭕(p)" "⸰(t)" "▶(n)" "⏸(w)" "|" "✔(d)" "❌(c)" "⏩(r)")))
>
> This works perfectly, so I can advance the todo-states, choose them
> directly, and filter on them in the agenda's todo-view, even org-edna,
> which heavily relies on them works as designed.
>
> While trying to use GTDs approach I defined a stuck project as one
> having no next action meaning, having no subheading with a todo state of "▶"
I don't see what can go wrong with unicode symbols for TODO keywords
when listing stuck projects.
Can you find `org-agenda-list-stuck-projects' with
C-h f org-agenda-list-stuck-projects RET
Go at the end of the function and instrument it with C-u C-M-x then
list stuck projects and see where the function chokes?
Thanks for your help,
--
Bastien
> I don't see what can go wrong with unicode symbols for TODO keywords > when listing stuck projects. Possibly related: - https://www.reddit.com/r/orgmode/comments/gdn1rt/can_i_actually_use_simpler_todo_keywords/ - (note the todo keywords used by the user) https://www.reddit.com/r/orgmode/comments/ef34sz/how_to_filter_headings_1_in_agenda/fc0kozx/ Best, Ihor Bastien <bzg@gnu.org> writes: > Hi Andreas, > > Andreas Drop <drops@mailbox.org> writes: > >> I configured my org-todo-keywords in a way, that they are just single >> unicode symbols instead of the classic TODO, NEXT, WAIT, DONE,etc. This is >> done in my init.el like this: >> >> (setq org-todo-keywords '((sequence "⭕(p)" "⸰(t)" "▶(n)" "⏸(w)" "|" "✔(d)" "❌(c)" "⏩(r)"))) >> >> This works perfectly, so I can advance the todo-states, choose them >> directly, and filter on them in the agenda's todo-view, even org-edna, >> which heavily relies on them works as designed. >> >> While trying to use GTDs approach I defined a stuck project as one >> having no next action meaning, having no subheading with a todo state of "▶" > > I don't see what can go wrong with unicode symbols for TODO keywords > when listing stuck projects. > > Can you find `org-agenda-list-stuck-projects' with > > C-h f org-agenda-list-stuck-projects RET > > Go at the end of the function and instrument it with C-u C-M-x then > list stuck projects and see where the function chokes? > > Thanks for your help, > > -- > Bastien
Bastien writes:
> Hi Andreas,
>
> I don't see what can go wrong with unicode symbols for TODO keywords
> when listing stuck projects.
>
> ... find `org-agenda-list-stuck-projects' ...
>
> Go at the end of the function and instrument it with C-u C-M-x then
> list stuck projects and see where the function chokes?
I just had the time to give it a deeper look. I can reproduce it with a
clean install of org 9.4, and I think I found the problematic code
file org-agenda.el:
(defun org-agenda-list-stuck-projects (&rest ignore)
.
.
.
(todo-re (and todo
(format "^\\*+[ \t]+\\(%s\\)\\>"
(mapconcat #'identity todo-wds "\\|"))))
.
.
.
I'm no elisp expert, but it looks to me, as if it builds a list of
regular expressions for every todo keyword in org-stuck-projects (todo-re) and it simply puts
the keyword in place of the %s
Each regex is then matched with every line that qualifies as a project
(found by the tags-re)
That works for normal keywords
"^\\*+[ \t]+\\(NEXT\\)\\"
matches with
** NEXT Task 1
BUT
"^\\*+[ \t]+\\(▶\\)\\"
DOES NOT match with
** ▶ Task 1
now my elisp knowledge is completely gone, but as I understood the
documentation for regex in elisp, unicode symbols have to be written
something like '\u1234' (out of my head) to work in a regex.
A minimal test.org:
* Project :project:
** ▶ Task 1
** ⸰ Task 2
A minimal init.el:
(setq org-todo-keywords '((sequence "⸰(t)" "▶(n)" "⏸(w)" "|" "✔(d)" "❌(c)" "⏩(r)")))
(setq org-stuck-projects '("project" ("NEXT" "▶") nil ""))
(setq org-agenda-files '("~/org/test.org"))
(setq org-tags-exclude-from-inheritance '("project"))
With this config the Project is marked as stuck even when it contains a
▶ keyword, when you change that to NEXT (which is not even a
valid todo-keyword here) it becomes unstuck.
Hope this helps
Andy