From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id aFuGJKURI2OZgQEAbAwnHQ (envelope-from ) for ; Thu, 15 Sep 2022 13:51:01 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id cL2tJKURI2NMSAEA9RJhRA (envelope-from ) for ; Thu, 15 Sep 2022 13:51:01 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 418363A027 for ; Thu, 15 Sep 2022 13:51:01 +0200 (CEST) Received: from localhost ([::1]:53002 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oYnOW-0000zS-8J for larch@yhetil.org; Thu, 15 Sep 2022 07:51:00 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36038) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYnLk-0000ww-TO for emacs-orgmode@gnu.org; Thu, 15 Sep 2022 07:48:10 -0400 Received: from relay12.mail.gandi.net ([217.70.178.232]:56405) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYnLi-0000yy-JO for emacs-orgmode@gnu.org; Thu, 15 Sep 2022 07:48:08 -0400 Received: (Authenticated sender: cschockaert@citadels.be) by mail.gandi.net (Postfix) with ESMTPA id DC77F200005 for ; Thu, 15 Sep 2022 11:48:01 +0000 (UTC) MIME-Version: 1.0 Date: Thu, 15 Sep 2022 13:48:01 +0200 From: Christophe Schockaert To: emacs-orgmode@gnu.org Subject: Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency In-Reply-To: <87czbyxh21.fsf@localhost> References: <2022-09-12T14-35-24@devnull.Karl-Voit.at> <87sfkwt3j4.fsf@localhost> <2022-09-13T10-02-59@devnull.Karl-Voit.at> <2022-09-13T17-47-35@devnull.Karl-Voit.at> <87czbyxh21.fsf@localhost> Message-ID: <8d386db549167ac3a2d9f20ba8079ab5@citadels.eu> X-Sender: R3vLibre@citadels.eu Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: none client-ip=217.70.178.232; envelope-from=R3vLibre@citadels.eu; helo=relay12.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1663242661; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=5SXKQfXS/Z66pqx3mtDbJzw7tlKh2RIZW2J+Vlv3+us=; b=MSNfeifkehBO9/3tCt9UF2HYHRFyc/TQF9USNJg4GSgfBe9BoEC7vTUihNZNxuooTbhl4N iQSmtUUNf4xpbDJeej/ko010e4HaBsmFnw8qZpBg4ebWdeUa+OQ/5J5hGzBE62epqM4SHh 36G8cHopwwn2PuavYyie++x7Usa9PvtiTkNiI61bTQXLatH3FcTSq2RRdJWlCID0m/+kaZ iQbzFmtSHwXY0iev4FgG/u+Kp8EPE9l52Uk83pYTcH3WBeaV4ymrV99lpNJDEepxiTyeV0 WRcHW5c5P6mDX3jd/Ea5zCaK871Iq2I2wa51dbapA2VKbPeavuUB10YXOZJnlg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1663242661; a=rsa-sha256; cv=none; b=j2ynN1X8nzG44w610CXro427W+GmtpKjzlcGPmEO+pZjO/buaeTMturB7ZJxW7dJ6hAkD1 rH9RctfulmM9RKPOd42Wccj6vO1rHuAQOGF6cKn7hZCWdVKW2XbmZtoiMWXy2vdkI8XDVm va4jZ1mRQ9gWDhCWCJzDiMI5TiTEVfQOzLGfsYXaxPUOTyXUw2bb797PukSR586cA5iuWa sdCos6oxM2s6mBqxMXI5MZ8dzLDRbMB/jeoPh5xuEzXcXDviORqYnrh1havakq95qB6qxw yFhJFsu2a2Dvraad5Gr4PAqgkl72Tro/XimrBXL4RFiH/spmCNVF8SLdwRyjZg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -2.73 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 418363A027 X-Spam-Score: -2.73 X-Migadu-Scanner: scn1.migadu.com X-TUID: 1HEl6wCb2XL0 On 2022-09-14 14:43, Ihor Radchenko wrote: > Karl Voit 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] <---------------<<<<