From: Karl Voit <devnull@Karl-Voit.at>
To: emacs-orgmode@gnu.org
Subject: Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
Date: Tue, 13 Sep 2022 17:52:36 +0200 [thread overview]
Message-ID: <2022-09-13T17-47-35@devnull.Karl-Voit.at> (raw)
In-Reply-To: f5644beb474fef6ad3fe9ef0ff629b6f@citadels.eu
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/
next prev parent reply other threads:[~2022-09-13 15:53 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
2022-09-13 15:52 ` Karl Voit [this message]
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=2022-09-13T17-47-35@devnull.Karl-Voit.at \
--to=devnull@karl-voit.at \
--cc=emacs-orgmode@gnu.org \
--cc=news2042@Karl-Voit.at \
/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).