From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id 4DXoKR10xGZlyAAAe85BDQ:P1 (envelope-from ) for ; Tue, 20 Aug 2024 10:46:53 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id 4DXoKR10xGZlyAAAe85BDQ (envelope-from ) for ; Tue, 20 Aug 2024 12:46:53 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=CQC2FYCW; dmarc=pass (policy=none) header.from=gmail.com; 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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1724150813; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=qB5t+GWOuC1jagGW8aVSyQko1jmRelAGZL7qLr1Msiw=; b=ZpRP1PzF3f847pKhEk7tmv+NcioBsGXiPl0cZuwNw8q6+ExoUqA7BtCnhDpB/NYXBftyR8 HKylUqpuO5aVzz6+MsJZXAuC+pqQpu+vkMU/cVTrizEk4lqZ2rTTQBPvvge/bhSZS1MR1l 0NaFAHPNl90aqI7Ub41AdXbl+DKkV4MFJ89YWzTSTQfcFnfbgC+UepL1ky8Y1JKOGXyY2o WPpqIxPHU49e6eN4DT14SZ5Sl2UpLeQkKm3OtmpcI2cbqy/8R5CprsbqpT+65G6eeHWRzM BETkUn4QMtrwD++ZVkjObCQSkmKJMV/zY154CDgo0kR1HfYYb/KNr8x4qjiOlA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1724150813; a=rsa-sha256; cv=none; b=TD2zI63hCrFiK/iho7JIMoDH6fwd0bX9Qf3+/Q5c1N1udIONVMrygv9EfllT1jrUAl7e6Y /OZbF7q3d4heYLcVH6J7M7dQDzIFqiH9U39mSZrKUOG/5nErvipP4DRhdtFusL3R7WmEeu aj/AaT3tLBjARccup+y4/X1ra8MRc3vCWh+4nux82vA/LiO9PCXeJXCLrddj6v8Bfd5RST Z2f7RG9MbhsoEqgujrG/VZ16p1oTZYDvLRPIvYVZ9thRzABrRPQQbzMB30gKycZmrbsx5e InAUvKuO1jbXNWG9D0ciLwA/NqqE0w08RtBq9LmNfy3EdreLM7Qwq3QJFcEbpg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=CQC2FYCW; dmarc=pass (policy=none) header.from=gmail.com; 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" 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 4E0F763D5D for ; Tue, 20 Aug 2024 12:46:53 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sgMN9-0005wo-4m; Tue, 20 Aug 2024 06:45:55 -0400 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 1sgMN6-0005nb-7q for emacs-orgmode@gnu.org; Tue, 20 Aug 2024 06:45:52 -0400 Received: from mail-lf1-x12f.google.com ([2a00:1450:4864:20::12f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sgMN3-0006an-N3 for emacs-orgmode@gnu.org; Tue, 20 Aug 2024 06:45:51 -0400 Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-52f042c15e3so4869989e87.0 for ; Tue, 20 Aug 2024 03:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724150747; x=1724755547; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qB5t+GWOuC1jagGW8aVSyQko1jmRelAGZL7qLr1Msiw=; b=CQC2FYCWoKcOVqp7WfVkVorUwqqbWyscvQNirIQhdVI0jF6Q64SwaJdO/m0Kyc61W9 pgqcRMFO1QAsja0ke56QoacjMjiZ1BU0AtTe657sOzdXK5+tTV33EC+asYq8ez9dgDV+ KeX+dg3pxoXfB+D/Ls6qZllYCaSgWG9sh5JJ8UtaLjxXytWQg7AGd89qva/m/iUmSkOn lU1y4cA/jRreg+L2zQLG75Co03CbiDwzTMflbqHwk+7/4Qa8vG/1bmpkiDZ7qAfE9P+o 5TCpcBpc3yR4qBZrvnjP/40tdc7QbX45gF+Vl5On+14u15hgoTIKw75XSMSDZGHMTuKl nbqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724150747; x=1724755547; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qB5t+GWOuC1jagGW8aVSyQko1jmRelAGZL7qLr1Msiw=; b=KQKdV03A+Vy8ZaCMjIVc3pcLsYjnxdoJtufvnQmz++zgw0pBNRSLAUvHxFWQZ3/l4T 2ZBjp2qlK6CGRZyRAqIO5a4ebnnbS6jp2kwCJgeHko4iGyG7OeFjAaRIxwCWZ9nsgeqa MAZa0IOhYGoSBbyrSGdg2ngDFo228dUb+Nexh2ZFq0aY6zDqEtiySTZLePt3cmlJEzdJ z8lndcbZuBbNHBwOiwk3+Q5YZ44aQ68pWLuV/EwjS5ZRuHr1Hc45ySUZSMqCDhDYTb+2 GwtjLBMbq2ApvN12K3VVFR+8uedJKzTZF3b3cioazunSz3KCatUo9cRNmfiv1JtRBmmJ +t5g== X-Forwarded-Encrypted: i=1; AJvYcCV4iLpfigJpmRLfXW+eEHNJ4kxQT6tKHBqxjTnXX2sO/jiVlUZv2buH0NmUNbQwhN6bQkN5YAdRgkmx7Dsd@gnu.org X-Gm-Message-State: AOJu0Yw/X3blUzf37aqu4ZCn+yGNSTxWY5Mz/gKSUm6FFIGQSIl8AKhr wal8nJBW89XNBlkJSZTQD7llmnBMpQ1NX0hTYKclebADojLC+fHSI+P/uxVMUfcR+3gA5gd+xqB Eohjw8Q7HW560BKn7HfSwyd/d9Rg= X-Google-Smtp-Source: AGHT+IHCOcDfkb6qxe5vZmVfH6CejMRlNYrlzlYLs6GuaK9RqbHCdTzyyIHC4MgIew4KRgULtTBiBDYZyo8A4KvZkHw= X-Received: by 2002:a05:6512:1085:b0:52f:cf2d:a1a0 with SMTP id 2adb3069b0e04-5333f2f1210mr952622e87.26.1724150746768; Tue, 20 Aug 2024 03:45:46 -0700 (PDT) MIME-Version: 1.0 References: <87ttn1f3b5.fsf@localhost> <87plwjmwhj.fsf@localhost> <18deb76f2d9.cad957fe1073948.9203602429479305690@excalamus.com> <87le743hli.fsf@localhost> <18df1207a7b.115a993991531101.8492317175658336513@excalamus.com> <87o7bw6by2.fsf@localhost> In-Reply-To: <87o7bw6by2.fsf@localhost> From: Carsten Dominik Date: Tue, 20 Aug 2024 12:45:30 +0200 Message-ID: Subject: Re: [PATCH] doc/org-manual.org (Checkboxes): move section 'Checkboxes' from 'TODO Items' to 'Plain Lists' To: Ihor Radchenko Cc: Matt , =?UTF-8?Q?S=C5=82awomir_Grochowski?= , emacs-orgmode Content-Type: multipart/alternative; boundary="000000000000ccef6206201b205a" Received-SPF: pass client-ip=2a00:1450:4864:20::12f; envelope-from=carsten.dominik@gmail.com; helo=mail-lf1-x12f.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -5.29 X-Spam-Score: -5.29 X-Migadu-Queue-Id: 4E0F763D5D X-Migadu-Scanner: mx11.migadu.com X-TUID: hHDk6O3/7rAd --000000000000ccef6206201b205a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Mar 2, 2024 at 1:40=E2=80=AFPM Ihor Radchenko = wrote: > Matt writes: > > > >...or did you not provided arguments /why/ the > > > section should be moved? I need to understand what kind of improveme= nt > > > it would provide to the manual. > > > > I didn't know that's what you were looking for. When I said, "I had > responded in favor..." it was in response to your prior message which sai= d, > > 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. > > > > This is incorrect albeit understandable. I had responded and, > therefore, there were not "no comments." However, it looks like I > responded in the wrong thread! ("Re: [PATCH] doc/org-manual.org: > Checkboxes, add checkbox states examples") That's my bad! > > I indeed missed your comment when writing this particular sentence. > > > Regarding reasoning, I'm in favor of the move for the reasons S=C5=82aw= omir > 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 > Items'. > > > > The issue is checkbox usage is split between different sections of the > manual. > > > > You had responded to this by saying, > > > >> Both arrangements are logical. Checkboxes are useful as a complement t= o > >> TODO items. And they are also indeed a plain list feature. > > > > It seems we're all agreed the proposed arrangement is logical and that > the 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 > arrangement 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* Carston moved it. This isn't a very contestable justification. > Checkboxes are meta data that is related to actions. Introducing checkboxes in the "Structure -> Plain lists" section would be similar to introducing TODO keywords in the "Headlines" section. Like you, I can find arguments for both arrangements - but this was the reasoning I used when I structured the manual. - Carsten > > I agree. > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at . > Support Org development at , > or support my work at > > --000000000000ccef6206201b205a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Mar 2, 2024 at 1:40=E2=80=AFP= M Ihor Radchenko <yantar92@posteo= .net> wrote:
Matt <matt@e= xcalamus.com> writes:

>=C2=A0 >...or did you not provided arguments /why/ the
>=C2=A0 > section should be moved? I need to understand what kind of = improvement
>=C2=A0 > it would provide to the manual.
>
> I didn't know that's what you were looking for.=C2=A0 When I s= aid, "I had responded in favor..." it was in response to your pri= or 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 w= ill
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.
>
> This is incorrect albeit understandable.=C2=A0 I had responded and, th= erefore, there were not "no comments."=C2=A0 However, it looks li= ke I responded in the wrong thread! ("Re: [PATCH] doc/org-manual.org: = Checkboxes, add checkbox states examples")=C2=A0 That's my bad!
I indeed missed your comment when writing this particular sentence.

> Regarding reasoning, I'm in favor of the move for the reasons S=C5= =82awomir gave:
>
>> Because checkbox can only exist in a plain list, as a plain list f= eature.
>> So the section should be under 'Plain Lists' heading not u= nder 'TODO Items'.
>
> The issue is checkbox usage is split between different sections of the= manual.
>
> You had responded to this by saying,
>
>> Both arrangements are logical. Checkboxes are useful as a compleme= nt 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 the issue is valid.=C2=A0 I don't think it needs extra justificati= on.

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 = arrangement we should use?
>
> Originally, we were reluctant to move the Checkboxes section only beca= use Carston had moved it previously.=C2=A0 Unfortunately, we don't know= *why* Carston moved it.=C2=A0 This isn't a very contestable justificat= ion.

Checkboxes are meta data that is r= elated to actions. Introducing checkboxes in the "Structure -> Plai= n lists" section would be similar to introducing TODO keywords in the = "Headlines" section. Like you, I can find arguments for both arra= ngements - but this was the reasoning I used when I structured the manual.<= /div>

- Carsten
=C2=A0

I agree.

--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,=
or support my work at <https://liberapay.com/yantar92>

--000000000000ccef6206201b205a--