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

[Karl Voit <devnull@Karl-Voit.at>]

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/