From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id 2HnyOFMe42WACAEA62LTzQ:P1 (envelope-from ) for ; Sat, 02 Mar 2024 13:40:52 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id 2HnyOFMe42WACAEA62LTzQ (envelope-from ) for ; Sat, 02 Mar 2024 13:40:52 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=CpYKiM94; 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"; dmarc=pass (policy=none) header.from=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1709383251; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc: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:dkim-signature; bh=1jG2tl/OBKCGtrnruLrP8LjAHFyvHPa6QdHNkkS6ZGk=; b=T7B85GcJmp5P2ZZOW+dXXBmlLsYDBNQ/z6S86lAY/MAji0J74XVRnM0D31p62VXv/eLW2Q PjavKstoYijVqrL5NNLcyZvC7CwK194d0Gdp7ENDQReH8hgWVpZLPqdHahYOyIlMWMNxET cLB3KIRw5v9c++fUUMbMQPHoPwY+iZ81uUovlbwEM9Huym6Xl9HkxHTFLffvhodhOe4RIS LZxikr5gwqKrzJxz+otOF1/xpmqO69+QjW9aIr0BEHMyF7iRcV1W0riK/O8p8yDW1Xn1EF escnrpDZ406QaTBqumbnLaQhpZmCP0iPxKi9ShH/Q5zdHchuqQLzYVzhgTGMNw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=CpYKiM94; 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"; dmarc=pass (policy=none) header.from=posteo.net ARC-Seal: i=1; s=key1; d=yhetil.org; t=1709383251; a=rsa-sha256; cv=none; b=fQoTuGAkMkK+GvLTEDOAeJWa6M5aas3/TVk3H7NHDUr41JVGmFLV4xiAUWeUFKHNEgEnL1 YrXOdVvt2IcFn3cd6Gv61R4fEdCesLbFOReNpvEiLXRxv55iuTgia6qoHMdWTakyxShKlI babJG21ayVIFgiznv9X3r4ZuysrMsgDtQE1LlLEEmjSOTCg/k0JVqsqPizy9krRAvgYWd7 NpQdsA454vkg7RQ+79hYkB0O0kzfXJWFsTtyxfBbId/TqlAfJD9CffwDC0mamNz1PFesnT 3/VQxUD2h8cxyfHLV81haiLvkHE/T+inrUvXDHt/43zsj2SZ9UAHdyzBtnxHfQ== 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 C89746A39E for ; Sat, 2 Mar 2024 13:40:50 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rgOej-00088v-MI; Sat, 02 Mar 2024 07:39:57 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rgOeg-00088L-8n for emacs-orgmode@gnu.org; Sat, 02 Mar 2024 07:39:54 -0500 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rgOed-0005Z0-TL for emacs-orgmode@gnu.org; Sat, 02 Mar 2024 07:39:54 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 1E56424002A for ; Sat, 2 Mar 2024 13:39:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1709383189; bh=SfKjaPzHSHDCCTDoBpLwv0VdAKZDjh+A8BEQ+ySMh7E=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding:From; b=CpYKiM94i34VT89d/2v5Mam+AnIIjmlidfCAY+GfW7mG0+wFOrVMQyN9OXCTFn1Cj XmL061rKSj9aXfEF/DsaDM7EO2ul7V+K27p9cLt/gbreawHxsuhLTm1ykBkdT8c0F7 DsLhBm6O44ksSO6nfHrxSDGsKkm3EU1ZwvGe3XUu1UR77AR5/nNugGG7DR5ct4WGwe QO9pSatmgN0rpXVEoBmVLeUNnC1R0/SxnfF3HRiRHdJqfIfGvHVq45WBmhU6Jtv0/M O0yjg0tkqAJ/uP6g9HGc7EwQgovscNVnQ3q3MYybu8XNGROC60/ET2YoYEJ9u6Vf4l Fi1owJ2WUPVkQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Tn4Kc1w1kz6tm8; Sat, 2 Mar 2024 13:39:48 +0100 (CET) From: Ihor Radchenko To: Matt Cc: =?utf-8?Q?S=C5=82awomir_Grochowski?= , emacs-orgmode Subject: Re: [PATCH] doc/org-manual.org (Checkboxes): move section 'Checkboxes' from 'TODO Items' to 'Plain Lists' In-Reply-To: <18df1207a7b.115a993991531101.8492317175658336513@excalamus.com> References: <87ttn1f3b5.fsf@localhost> <87plwjmwhj.fsf@localhost> <18deb76f2d9.cad957fe1073948.9203602429479305690@excalamus.com> <87le743hli.fsf@localhost> <18df1207a7b.115a993991531101.8492317175658336513@excalamus.com> Date: Sat, 02 Mar 2024 12:43:49 +0000 Message-ID: <87o7bw6by2.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -9.47 X-Spam-Score: -9.47 X-Migadu-Queue-Id: C89746A39E X-Migadu-Scanner: mx11.migadu.com X-TUID: x3JvI65MRwIp Matt writes: > >...or did you not provided arguments /why/ the > > section should be moved? I need to understand what kind of improvement > > it would provide to the manual. > > I didn't know that's what you were looking for. When I said, "I had resp= onded in favor..." it was in response to your prior message which said, Let me clarify. I am personally neutral about where the concept of checkboxes is introduced. Either way is generally possible. However, moving "Checkboxes" section will require some work. We will need to make sure that the overall flow of the manual is _improved_. The question is how to judge "improved". >From my point of view, the manual will be improved by the proposed change if (a) we can see clear logical argument why the proposed rearrangement is superior; or/and (b) *a number* of Org users /feel/ that the rearrangement will improve thins. Your response is in favor, but you did not appear to present logical arguments. So, I classify your response as if you /feel/ that the rearrangement will be better. Such response of a single person is not very convincing. I'd only see rearrangement justified if many users are in favor. Another question is when there is a clear logical argument. Such argument would not require multiple users to agree as it would stand by its own. >> No comments arrived within one month.=20 > > This is incorrect albeit understandable. I had responded and, therefore,= there were not "no comments." However, it looks like I responded in the w= rong thread! ("Re: [PATCH] doc/org-manual.org: Checkboxes, add checkbox sta= tes examples") That's my bad!=20 I indeed missed your comment when writing this particular sentence. > Regarding reasoning, I'm in favor of the move for the reasons S=C5=82awom= ir gave: > >> Because checkbox can only exist in a plain list, as a plain list feature. >> So the section should be under 'Plain Lists' heading not under 'TODO Ite= ms'. > > The issue is checkbox usage is split between different sections of the ma= nual. > > You had responded to this by saying, > >> Both arrangements are logical. Checkboxes are useful as a complement to >> TODO items. And they are also indeed a plain list feature. > > It seems we're all agreed the proposed arrangement is logical and that th= e issue is valid. I don't think it needs extra justification. Yes, the proposed arrangement is logical. So is the existing arrangement. The problem is that I do not see why the proposed arrangement is *better*. > Conceding this point, which we all appear to, the issue becomes which arr= angement we should use? > > Originally, we were reluctant to move the Checkboxes section only because= Carston had moved it previously. Unfortunately, we don't know *why* Carst= on moved it. This isn't a very contestable justification. I agree. --=20 Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at