From: Christophe Schockaert <R3vLibre@citadels.eu>
To: emacs-orgmode@gnu.org
Subject: Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
Date: Thu, 15 Sep 2022 13:48:01 +0200 [thread overview]
Message-ID: <8d386db549167ac3a2d9f20ba8079ab5@citadels.eu> (raw)
In-Reply-To: <87czbyxh21.fsf@localhost>
On 2022-09-14 14:43, Ihor Radchenko wrote:
> Karl Voit <devnull@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] <---------------<<<<
next prev parent reply other threads:[~2022-09-15 11:51 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
2022-09-14 12:43 ` Ihor Radchenko
2022-09-15 11:48 ` Christophe Schockaert [this message]
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=8d386db549167ac3a2d9f20ba8079ab5@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).