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