From: Karl Voit <devnull@Karl-Voit.at>
To: emacs-orgmode@gnu.org
Subject: Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
Date: Mon, 19 Sep 2022 13:10:35 +0200 [thread overview]
Message-ID: <2022-09-19T13-04-02@devnull.Karl-Voit.at> (raw)
In-Reply-To: 8d386db549167ac3a2d9f20ba8079ab5@citadels.eu
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/
next prev parent reply other threads:[~2022-09-19 11:11 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
2022-09-16 4:59 ` Ihor Radchenko
2022-09-19 11:10 ` Karl Voit [this message]
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-19T13-04-02@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).