Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
Ihor Radchenko writes: > For reference, I am seeing this feature as a step towards better > modularity of org-list.el. Modularity is good if we have use-cases for it, at least one feature relying on it. I wouldn't implement a feature just to add modularity. > The current list code is rather monolithic > and leaves no room for user customization of the commands. (Also, see > recent discussions about converting between lists and headings > https://list.orgmode.org/orgmode/877d4luxb8.fsf@localhost/ > https://orgmode.org/list/877d3k70lu.fsf@localhost) I'm not convinced the first report is a bug in the way list are handled. The second is a bug in the way headings are transformed as list items (leaving footnotes in a poor state). If more modularity helps fixing these edge cases, then why not. > Even if we do not provide "canceled" items in lists, having an > infrastructure to customize list commands better will be a good thing to > have. Of course, I guess you can think of useful customization of list commands -- perhaps that what we should think about first: would it be a good thing to allow customization of list commands? what use-case? 2 cts, -- Bastien
Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
> "TC" == Tim Cross writes: TC> At any rate, at this point, I suspect this is something best TC> handled in individual configurations rather than attempting to TC> impose a specific interpretation on everyone. If someone needs TC> help to write a simple command to 'toggle' checkbox TC> cancellation, I'm sure asking here will get some assistance. To have it well integrated, at least the following functionality is needed: - To change to and from the canceled state. - To clear all the list items statuses. - Making all the related functionality (blockers, agenda, …) to recognize when a task list with canceled items is finished. - Making it well working with things like org-modern. It’s fair to say the functionality is not suitable for implementation in Org for some reason (too complicated, unclear how to do it properly, almost nobody needs it, …) but let’s not pretend it’s something that can be added to an individual configuration easily. Not that the above couldn’t be implemented privately but the effort would be significant and the hack would be ugly (modifying org-ctrl-c-ctrl-c? uh) and non-portable (different markups by different users). My Org configuration is already cluttered enough and I rather keep living without this functionality than polluting it with additional hacks.
Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
Tim Cross writes: > +1. As usual, I'm concerned about over engineering and over > complicating matters for corner cases. As you correctly point out, > implementing something here is likely to force a specific interpretation > of cancelled with may not fit with other interpretations. For reference, I am seeing this feature as a step towards better modularity of org-list.el. The current list code is rather monolithic and leaves no room for user customization of the commands. (Also, see recent discussions about converting between lists and headings https://list.orgmode.org/orgmode/877d4luxb8.fsf@localhost/ https://orgmode.org/list/877d3k70lu.fsf@localhost) Even if we do not provide "canceled" items in lists, having an infrastructure to customize list commands better will be a good thing to have. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
Bastien writes: > Daniel Fleischer writes: > >> At first it makes sense, but we do have headlines and TODO keywords to >> express different states, colors and even sets of states. This is just a >> checklist construct. I think if I wanted to mark something as canceled >> or not relevant I would do something like this: >> >> - [ ] this is important. >> - [X] +canceled+ this is not important. >> >> or even strike through everything. > > FWIW, I use this: > > - [X] +This task will probably be canceled+ > > I don't think we should implement a new status for canceled tasks. > On top of the implementation (C-u C-u C-u C-c C-c ?), I believe it > is more flexible to be able to let canceled tasks block the whole > set of tasks---or not. So both these tasks seem useful to me: > > - [X] +A canceled task+ > - [-] +A canceled task+ > > Implementing "canceled tasks" will probably force one interpretation > over another, we lose in flexibility and readability. > > 2 cts, +1. As usual, I'm concerned about over engineering and over complicating matters for corner cases. As you correctly point out, implementing something here is likely to force a specific interpretation of cancelled with may not fit with other interpretations. If you do have a workflow which requires 'cancelling' check list items frequently enough that adding surrounding + is too inconvenient, I doubt it would be hard to write a simple command to add/remove surrounding markers. At any rate, at this point, I suspect this is something best handled in individual configurations rather than attempting to impose a specific interpretation on everyone. If someone needs help to write a simple command to 'toggle' checkbox cancellation, I'm sure asking here will get some assistance.
Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
> "B" == Bastien writes: B> FWIW, I use this: B> - [X] +This task will probably be canceled+ B> I don't think we should implement a new status for canceled B> tasks. Such a workaround doesn’t work well for lists that are to be re-used next time or cleared when the whole task is repeating and is switched to done. Checkboxes can always be cleared easily using a single rectangular command if there is no automatic mechanism but how to clear the + marks? A typical example would be my checklist for items to take with when traveling. Some of the items are already in my bag, some must be inserted there and some are not needed this time. Using +strike through+ is cumbersome, defining a command for it doesn’t feel good, and there is the problem of clearing the marks when re-using the list next time. Well, I do not store that particular list in a task node so I can use [-] freely but it’s still inconsistent with the actual meaning defined by Org. Not that big deal but it would be nice to have an official way to mark an item as not-applicable / canceled and not blocking finishing the task.
Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
Daniel Fleischer writes: > At first it makes sense, but we do have headlines and TODO keywords to > express different states, colors and even sets of states. This is just a > checklist construct. I think if I wanted to mark something as canceled > or not relevant I would do something like this: > > - [ ] this is important. > - [X] +canceled+ this is not important. > > or even strike through everything. FWIW, I use this: - [X] +This task will probably be canceled+ I don't think we should implement a new status for canceled tasks. On top of the implementation (C-u C-u C-u C-c C-c ?), I believe it is more flexible to be able to let canceled tasks block the whole set of tasks---or not. So both these tasks seem useful to me: - [X] +A canceled task+ - [-] +A canceled task+ Implementing "canceled tasks" will probably force one interpretation over another, we lose in flexibility and readability. 2 cts, -- Bastien
Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
Hi, * Christophe Schockaert wrote: > As for me, I am interested in having a way to manage cancels. > > I have always managed it with workarounds up to now, so it would be nice > to have a clean way for it. "Clean" depends on the definition. To me, a general convention with the statement that it does not have any tool-implication (progress indicators, ...) would also be cool. Maybe there will be an elisp function to toggle cancelled/non-cancelled list items instead of everybody is doing this in his/her own setup. > However, this is low priority to me regarding the effort to provide. > Also, since the suggestion from Daniel, I can consider it as a viable > option for my use case, to keep lists simple and use the strikethrough > would improve my readability. I agree. > This would allow several behaviors for counting the checkboxes as we > please : > > * TODO [2/2] Several checkboxes > > - [X] This one is done > - [X] +This once is cancelled as done+ > - +[ ] This one is forgotten completely+ And: - +[ ]+ This is cancelled ... which does not require or impose multi-line formatting to mark it as cancelled. > (my wish would be to have a robust way to handle multilines formating, > but that’s on another topic going on ^^) Yes, but probably not that easy. > I don’t know what’s the usual process : can’t we file an issue to track > it, and write down the options we have, then decide the outcome of it > (either development, or documenting options and ideas) ? Documenting a convention is good enough to me. At least people don't get too creative with different conventions by themselves which adds complexity when Orgdown files are shared among different people. I'm still dreaming of fool-proof real-world and real-time collaboration on Orgdown files using GNU Emacs and probably other tools as well. > Regarding the checkbox state, I wanted to have the impression of > maintainers, but I felt that choosing the character would not be easy to > handle not only for development, but even for reading documents from > different sources (custom TODO states have a meaning that we can infer, > but a single letter seems harder). > > As an after thought, about the "[C]" proposal, I wonder if it would not > be better to have a symbol, as "[X]" is not used for the letter, but for > the cross, same for the "space" and the "dash" which express "halfway > through". I didn’t have any idea the other day, but meanwhile, I have > come first with "[~]" which sounds like a wave and thus is not firm, and > is also a bitwise NOT in some programming languages. It could be easily mixed up with [-] - depending on font size, font style, and such. > Or, thinking about the "NOT", I thought about "[!]" which is a NOT > (not done) and also quite expressive. The only thing is that it is > quite catching attention, like if we need to pay attention for > something that was probably not that important since we cancelled > it :) I could not find many other options, as I feel we need to > stick to ASCII for a solution. An exclamation mark imposes importance from my point of view. > WDYT ? > Christophe HTH -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
Christophe Schockaert writes: > (my wish would be to have a robust way to handle multilines formating, > but that’s on another topic going on ^^) > > I don’t know what’s the usual process : can’t we file an issue to track > it, and write down the options we have, then decide the outcome of it > (either development, or documenting options and ideas) ? Just drop an email with appropriate subject. > Regarding the checkbox state, I wanted to have the impression of > maintainers, but I felt that choosing the character would not be easy to > handle not only for development, but even for reading documents from > different sources (custom TODO states have a meaning that we can infer, > but a single letter seems harder). > > As an after thought, about the "[C]" proposal, I wonder if it would not > be better to have a symbol, as "[X]" is not used for the letter, but for > the cross, same for the "space" and the "dash" which express "halfway > through". I didn’t have any idea the other day, but meanwhile, I have > come first with "[~]" which sounds like a wave and thus is not firm, and > is also a bitwise NOT in some programming languages. Or, thinking about > the "NOT", I thought about "[!]" which is a NOT (not done) and also > quite expressive. The only thing is that it is quite catching attention, > like if we need to pay attention for something that was probably not > that important since we cancelled it :) I could not find many other > options, as I feel we need to stick to ASCII for a solution. > > > WDYT ? I think that choosing a character is of a secondary importance. It can be easily adjusted once we have a working code. Getting the working code is much harder though. Someone™ will need to submit a patch first. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
On 2022-09-14 14:43, Ihor Radchenko wrote: Karl Voit writes: So, to me the main use case to have an explicit cancel, is when I have a long list, and to remember that I stated it as "cancelled". If we go that way, having no other nice idea at the moment, I quite like the [C] which is explicit although language specific. ... if it is possible with the current implementation, we could introduce an official convention that any single (upper case?) character between the brackets is interpreted as a non-open checkbox. So any user is able to choose her character of choice even language-dependent. I do not like the idea of pre-defining a meaning of an arbitrary single character. This will leave too less flexibility for future. As for cancelled state, it makes sense to add it. I have seen cancelled state in other outliners. However, adding a new checkbox state will involve changing Org syntax (https://orgmode.org/worg/dev/org-syntax.html#Items). Also, list implementation in Org is not particularly modular---someone will need to go across the code and make sure that new checkbox state is not going to break anything. The manual will also need to be updated. To conclude, if there is sufficient interest, I do not see why not. But it will be an involved change in Org code someone will need to perform. As for me, I am interested in having a way to manage cancels. I have always managed it with workarounds up to now, so it would be nice to have a clean way for it. However, this is low priority to me regarding the effort to provide. Also, since the suggestion from Daniel, I can consider it as a viable option for my use case, to keep lists simple and use the strikethrough would improve my readability. This would allow several behaviors for counting the checkboxes as we please : * TODO [2/2] Several checkboxes - [X] This one is done - [X] +This once is cancelled as done+ - +[ ] This one is forgotten completely+ (my wish would be to have a robust way to handle multilines formating, but that’s on another topic going on ^^) I don’t know what’s the usual process : can’t we file an issue to track it, and write down the options we have, then decide the outcome of it (either development, or documenting options and ideas) ? Regarding the checkbox state, I wanted to have the impression of maintainers, but I felt that choosing the character would not be easy to handle not only for development, but even for reading documents from different sources (custom TODO states have a meaning that we can infer, but a single letter seems harder). As an after thought, about the "[C]" proposal, I wonder if it would not be better to have a symbol, as "[X]" is not used for the letter, but for the cross, same for the "space" and the "dash" which express "halfway through". I didn’t have any idea the other day, but meanwhile, I have come first with "[~]" which sounds like a wave and thus is not firm, and is also a bitwise NOT in some programming languages. Or, thinking about the "NOT", I thought about "[!]" which is a NOT (not done) and also quite expressive. The only thing is that it is quite catching attention, like if we need to pay attention for something that was probably not that important since we cancelled it :) I could not find many other options, as I feel we need to stick to ASCII for a solution. WDYT ? Christophe -- ---> https://www.citadels.earth Once it's perfectly aimed, the flying arrow goes straight to its target. Thus, don't worry when things go right. There will be enough time to worry about if they go wrong. Then, it's time to fire a new arrow towards another direction. Don't sink. Adapt yourself ! The archer has to shoot accurately and quickly. [Words of Erenthar, the bowman ranger] <---
Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
Karl Voit [2022-09-13 Tue 10:07] wrote: > Is it only me who is thinking that a non-blocking cancelled checkbox > state would be a good idea? At first it makes sense, but we do have headlines and TODO keywords to express different states, colors and even sets of states. This is just a checklist construct. I think if I wanted to mark something as canceled or not relevant I would do something like this: - [ ] this is important. - [X] +canceled+ this is not important. or even strike through everything. I think it's consistent in terms of statistics; you want the total number to represent what you wrote down and what's left does not include the "canceled" tasks. -- Daniel Fleischer
Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
Karl Voit writes: >> So, to me the main use case to have an explicit cancel, is when I have a >> long list, and to remember that I stated it as "cancelled". >> If we go that way, having no other nice idea at the moment, I quite like >> the [C] which is explicit although language specific. > > ... if it is possible with the current implementation, we could > introduce an official convention that any single (upper case?) > character between the brackets is interpreted as a non-open > checkbox. So any user is able to choose her character of choice even > language-dependent. I do not like the idea of pre-defining a meaning of an arbitrary single character. This will leave too less flexibility for future. As for cancelled state, it makes sense to add it. I have seen cancelled state in other outliners. However, adding a new checkbox state will involve changing Org syntax (https://orgmode.org/worg/dev/org-syntax.html#Items). Also, list implementation in Org is not particularly modular---someone will need to go across the code and make sure that new checkbox state is not going to break anything. The manual will also need to be updated. To conclude, if there is sufficient interest, I do not see why not. But it will be an involved change in Org code someone will need to perform. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
Hi Christophe, * Christophe Schockaert wrote: > > In a sense I can feel it’s useful to have an explicit cancel while > working. > But I don’t know how to handle it (see below). > I don’t think [/] would be a good candidate anyway, it’s used as a > statistic cookie, so it already has a meaning and would be confusing, > also it gets evaluated even in the body entry. > > Actually, I almost always use statistic cookies when using checkboxes, > and so how would we count the cancelled checkbox ? That was a huge mistake by me. I obviously did not think before choosing one of the few characters in between those brackets that are a clear no-go as you have mentioned above. Sorry. > As I didn’t imagine to alter the syntax as used it as it : > > - either, I add a note (usually dated) explicitly stating it’s > cancelled, and I check the box A viable workaround, yes. > - or, I force the closing of the whole entry with the C-u sequence, and > so it’s clear that some were cancelled or at least not fulfilled (which > in sort means that its follow up has been cancelled), as it writes [2/3] > in the heading for example. As the checkboxes don’t appear in the > agenda, it does not bother me so much to leave them uncompleted. Yes, also a workaround. I never used the C-u sequence for overriding that blocking feature so far. > * DONE [2/3] Some tasks to check >- [X] check 1 >- [ ] check 2 > - [2022-09-13] Cancelled. Won’t check this one >- [X] check 3 > > So, to me the main use case to have an explicit cancel, is when I have a > long list, and to remember that I stated it as "cancelled". > If we go that way, having no other nice idea at the moment, I quite like > the [C] which is explicit although language specific. ... if it is possible with the current implementation, we could introduce an official convention that any single (upper case?) character between the brackets is interpreted as a non-open checkbox. So any user is able to choose her character of choice even language-dependent. > However, this rises the question for the completeness : > > * TODO [1/3] Some tasks to check >- [X] check 1 >- [C] check 2 (or any other chosen token for [C]) >- [ ] check 3 > > Should we display [1/3] or [2/3] ? > Maybe we should align against the way it works for TODO/DONE/CANCELLED, > so it would be [2/3]... I'd say we should stick to that pattern, yes. > On the other hand, the "DONE [2/3]" above is quite visually explicit > that something was not fulfilled for the course of resolving the action. > > I hope this brought something useful for the thinking :) Oh yes, thank you! -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
On 2022-09-13 10:07, Karl Voit wrote: Hi Ihor, * Ihor Radchenko wrote: Karl Voit writes: I was using list checkboxes like that: - [ ] open task - [X] closed task - [-] cancelled task From the manual (5.6 Checkboxes): ‘C-c C-x C-b’ (‘org-toggle-checkbox’) Toggle checkbox status or—with prefix argument—checkbox presence at point. With double prefix argument, set it to ‘[-]’, which is considered to be an intermediate state. [-] is not considered done by our conventions ... So, you can use something like - [C] cancelled task But beware that this is an internal implementation detail that might be changed in future unless we decide to document the existing behaviour. In that case, I prefer not to depend on that internal detail and start using +[ ]+ as a workaround which causes the parser to not detect a checkbox at all, as far as I understood. Thanks for clarification. If we wanted to introduce a cancelled checkbox state, it seems to be the case that this would require a new approach like [/] or similar. Is it only me who is thinking that a non-blocking cancelled checkbox state would be a good idea? Hello Karl and all, In a sense I can feel it’s useful to have an explicit cancel while working. But I don’t know how to handle it (see below). I don’t think [/] would be a good candidate anyway, it’s used as a statistic cookie, so it already has a meaning and would be confusing, also it gets evaluated even in the body entry. Actually, I almost always use statistic cookies when using checkboxes, and so how would we count the cancelled checkbox ? As I didn’t imagine to alter the syntax as used it as it : - either, I add a note (usually dated) explicitly stating it’s cancelled, and I check the box - or, I force the closing of the whole entry with the C-u sequence, and so it’s clear that some were cancelled or at least not fulfilled (which in sort means that its follow up has been cancelled), as it writes [2/3] in the heading for example. As the checkboxes don’t appear in the agenda, it does not bother me so much to leave them uncompleted. * DONE [2/3] Some tasks to check - [X] check 1 - [ ] check 2 - [2022-09-13] Cancelled. Won’t check this one - [X] check 3 So, to me the main use case to have an explicit cancel, is when I have a long list, and to remember that I stated it as "cancelled". If we go that way, having no other nice idea at the moment, I quite like the [C] which is explicit although language specific. However, this rises the question for the completeness : * TODO [1/3] Some tasks to check - [X] check 1 - [C] check 2 (or any other chosen token for [C]) - [ ] check 3 Should we display [1/3] or [2/3] ? Maybe we should align against the way it works for TODO/DONE/CANCELLED, so it would be [2/3]... On the other hand, the "DONE [2/3]" above is quite visually explicit that something was not fulfilled for the course of resolving the action. I hope this brought something useful for the thinking :) Christophe PS to Ihor while I am at it : Thank you very much for your answer to a (very) past question of mine, I made some progress meanwhile, I’ll make an update when I can :) -- ---> https://www.citadels.earth Once it's perfectly aimed, the flying arrow goes straight to its target. Thus, don't worry when things go right. There will be enough time to worry about if they go wrong. Then, it's time to fire a new arrow towards another direction. Don't sink. Adapt yourself ! The archer has to shoot accurately and quickly. [Words of Erenthar, the bowman ranger] <---
Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
On 2022-09-13, at 10:07, Karl Voit wrote: > Is it only me who is thinking that a non-blocking cancelled checkbox > state would be a good idea? No. -- Marcin Borkowski http://mbork.pl
Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
Hi Ihor, * Ihor Radchenko wrote: > Karl Voit writes: > >> I was using list checkboxes like that: >> - [ ] open task >> - [X] closed task >> - [-] cancelled task > > From the manual (5.6 Checkboxes): > > ‘C-c C-x C-b’ (‘org-toggle-checkbox’) > Toggle checkbox status or—with prefix argument—checkbox presence at > point. With double prefix argument, set it to ‘[-]’, which is > considered to be an intermediate state. > > [-] is not considered done by our conventions > >Here is an example of a checkbox list. > > * TODO Organize party [2/4] >- [-] call people [1/3] > - [ ] Peter > - [X] Sarah > - [ ] Sam >- [X] order food >- [ ] think about what music to play >- [X] talk to the neighbors Yes, that makes sense. [-] is not a candidate for a cancelled checkbox for that reason. :-( >> (setq org-enforce-todo-checkbox-dependencies t) >> ... any [-] checkbox will be regarded as non-finished contrary to >> the behavior of TODO/DONE/CANCELLED heading states. >> >> As a workaround, I may use: >> - +[ ]+ cancelled task > > As you can see, we already have conflicting convention, and we cannot > change it without breaking backwards compatibility. > > `org-block-todo-from-checkboxes', currently uses > > (org-list-search-forward >(concat (org-item-beginning-re) >"\\(?:\\[@\\(?:start:\\)?\\([0-9]+\\|[A-Za-z]\\)\\][ > \t]*\\)?" >"\\[[- ]\\]") >end t) > > as a condition that some list items are marked incomplete. > > So, you can use something like > - [C] cancelled task > > But beware that this is an internal implementation detail that might be > changed in future unless we decide to document the existing behaviour. In that case, I prefer not to depend on that internal detail and start using +[ ]+ as a workaround which causes the parser to not detect a checkbox at all, as far as I understood. Thanks for clarification. If we wanted to introduce a cancelled checkbox state, it seems to be the case that this would require a new approach like [/] or similar. Is it only me who is thinking that a non-blocking cancelled checkbox state would be a good idea? -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
Karl Voit writes: > I was using list checkboxes like that: > > - [ ] open task > - [X] closed task > - [-] cancelled task > > The latter one is supported via C-u C-u C-c C-c. >From the manual (5.6 Checkboxes): ‘C-c C-x C-b’ (‘org-toggle-checkbox’) Toggle checkbox status or—with prefix argument—checkbox presence at point. With double prefix argument, set it to ‘[-]’, which is considered to be an intermediate state. [-] is not considered done by our conventions Here is an example of a checkbox list. * TODO Organize party [2/4] - [-] call people [1/3] - [ ] Peter - [X] Sarah - [ ] Sam - [X] order food - [ ] think about what music to play - [X] talk to the neighbors > However, when I'm using: > > (setq org-enforce-todo-checkbox-dependencies t) > > ... any [-] checkbox will be regarded as non-finished contrary to > the behavior of TODO/DONE/CANCELLED heading states. > > As a workaround, I may use: > > - +[ ]+ cancelled task > > ... but this is tedious. > > Therefore I'm asking if this might be a viable syntax change: > handling [-] list items similar to CANCELLED headings as > non-blocking when used with org-enforce-todo-checkbox-dependencies. As you can see, we already have conflicting convention, and we cannot change it without breaking backwards compatibility. `org-block-todo-from-checkboxes', currently uses (org-list-search-forward (concat (org-item-beginning-re) "\\(?:\\[@\\(?:start:\\)?\\([0-9]+\\|[A-Za-z]\\)\\][ \t]*\\)?" "\\[[- ]\\]") end t) as a condition that some list items are marked incomplete. So, you can use something like - [C] cancelled task But beware that this is an internal implementation detail that might be changed in future unless we decide to document the existing behaviour. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
