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