Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency

Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency

[Karl Voit]

Hi,

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.

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.


Tested with Org mode version 9.5.3.

-- 
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

[Ihor Radchenko]

Karl Voit <devnull@Karl-Voit.at> 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

Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency

[Karl Voit]

Hi Ihor,

* Ihor Radchenko <yantar92@gmail.com> wrote:
> Karl Voit <devnull@Karl-Voit.at> 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

[Marcin Borkowski]

On 2022-09-13, at 10:07, Karl Voit <devnull@Karl-Voit.at> 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

[Christophe Schockaert]

On 2022-09-13 10:07, Karl Voit wrote:
> Hi Ihor,
> 
> * Ihor Radchenko <yantar92@gmail.com> wrote:
>> Karl Voit <devnull@Karl-Voit.at> 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

[Karl Voit]

Hi Christophe,

* Christophe Schockaert <R3vLibre@citadels.eu> 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

[Ihor Radchenko]

Karl Voit <devnull@Karl-Voit.at> 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

[Daniel Fleischer]

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

[Christophe Schockaert]

On 2022-09-14 14:43, Ihor Radchenko wrote:
> Karl Voit <devnull@Karl-Voit.at> 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

[Ihor Radchenko]

Christophe Schockaert <R3vLibre@citadels.eu> 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

[Karl Voit]

Hi,

* Christophe Schockaert <R3vLibre@citadels.eu> 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

[Bastien]

Daniel Fleischer <danflscr@gmail.com> 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

[Milan Zamazal]

>>>>> "B" == Bastien  <bzg@gnu.org> 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

[Tim Cross]

Bastien <bzg@gnu.org> writes:

> Daniel Fleischer <danflscr@gmail.com> 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

[Ihor Radchenko]

Tim Cross <theophilusx@gmail.com> 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

[Milan Zamazal]

>>>>> "TC" == Tim Cross <theophilusx@gmail.com> 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

[Bastien]

Ihor Radchenko <yantar92@gmail.com> 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