From: Christophe Schockaert <R3vLibre@citadels.eu>
To: Emacs Orgmode <emacs-orgmode@gnu.org>
Subject: Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
Date: Tue, 13 Sep 2022 13:07:13 +0200 [thread overview]
Message-ID: <f5644beb474fef6ad3fe9ef0ff629b6f@citadels.eu> (raw)
In-Reply-To: <2022-09-13T10-02-59@devnull.Karl-Voit.at>
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] <---------------<<<<
next prev parent reply other threads:[~2022-09-13 11:10 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-12 12:40 Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency Karl Voit
2022-09-13 2:24 ` Ihor Radchenko
2022-09-13 8:07 ` Karl Voit
2022-09-13 10:44 ` Marcin Borkowski
2022-09-13 11:07 ` Christophe Schockaert [this message]
2022-09-13 15:52 ` Karl Voit
2022-09-14 12:43 ` Ihor Radchenko
2022-09-15 11:48 ` Christophe Schockaert
2022-09-16 4:59 ` Ihor Radchenko
2022-09-19 11:10 ` Karl Voit
2022-09-14 18:18 ` Daniel Fleischer
2022-09-22 15:03 ` Bastien
2022-09-22 17:19 ` Milan Zamazal
2022-09-22 23:19 ` Tim Cross
2022-09-23 2:46 ` Ihor Radchenko
2022-09-25 2:59 ` Bastien
2022-09-24 8:09 ` Milan Zamazal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f5644beb474fef6ad3fe9ef0ff629b6f@citadels.eu \
--to=r3vlibre@citadels.eu \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).