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