emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Karl Voit
Subject: Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
Date: Tue, 13 Sep 2022 17:52:36 +0200
User-agent: slrn/1.0.3 (Linux)

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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]