From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.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 UDjqCo4nr2K3vAAAbAwnHQ (envelope-from ) for ; Sun, 19 Jun 2022 15:41:34 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id oGb0CY4nr2KrEwAAG6o9tA (envelope-from ) for ; Sun, 19 Jun 2022 15:41:34 +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 97B271236D for ; Sun, 19 Jun 2022 15:41:33 +0200 (CEST) Received: from localhost ([::1]:43128 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o2vBE-0007u1-NQ for larch@yhetil.org; Sun, 19 Jun 2022 09:41:32 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57146) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o2vAK-0007tZ-Pk for emacs-orgmode@gnu.org; Sun, 19 Jun 2022 09:40:38 -0400 Received: from mail-wr1-x431.google.com ([2a00:1450:4864:20::431]:46998) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o2vAJ-0000zv-5q for emacs-orgmode@gnu.org; Sun, 19 Jun 2022 09:40:36 -0400 Received: by mail-wr1-x431.google.com with SMTP id e25so7460406wrc.13 for ; Sun, 19 Jun 2022 06:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=h6N0cIOvaQS9eCGf5m/zBZRpyUneeHpTQOf2Jyh2v3w=; b=Ut/mGCOmmguwV0tQhemtaH3E6Tm+rU4eqWFUrk6uxbY8/nFKeaRXciy/8EiWH/Um28 C6x7CdwkjaVzkvKVfyO9lTxXSC+mh/zpybFy+x72r8ZOjWuF7XfHH2oRy54+iqF1mnvn ZgzkEXozPXRUqVluXuJ/cBX7e+Ps79bQRxfmFEL7ScjoxFLWcNz+eit31CY7TJliyDeK 3fszuQCfFCU5Sv9ZREmW1HfZKg6QKxkpMPylN0WBZz7tQ/SxrpoGvDY3me2YA+lICDLt SlWT9l6gS2KwTbr9lMOFagnsa3mFsjuejI9chP+eqTK38prlf/j2DF7DnDUkFWHTBADj QNPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=h6N0cIOvaQS9eCGf5m/zBZRpyUneeHpTQOf2Jyh2v3w=; b=gbFuxZcR/1XG4ZuVNfoVAcox4o/SeX4uZeF8iy2rFzScMMKDVlczNLodPRD8SCAjso /2Jv6yzMIVG2BkCEjwXvpgaEKn8tiBHyIgGFJi8xjEsD1OVqJMbVC4P2FS6JzpgRFQF8 5vegjy46/WLf0aWuEo2rx8H8/r6xuIEkxHYCN4FLj5QLm+ezLbWxPdyZ7ED2+v7vbClk MKPWiOAQA6zEm0X+5BlDuPY0Fq4D7ptR02ZTA2DiiNQ7hd5qflXeKavbBGyRU+Fc7rS9 IffwYEnISBeQk40UyeiUOJf0S34yG3sg+4pnLcga2hzgRLp0vFL2HcJN/E1VjDpsXnpj yixw== X-Gm-Message-State: AJIora/q45UF1vImuUKnPV6gMFMXlTS7GeVpHDoS6ecwzAuHeggfxo/i dDX0aAXqVmzwlO2+WGJWlpOsjDh7AM7TwQ== X-Google-Smtp-Source: AGRyM1sGDXe5aFFUzgKlS3COB1HzCdORDmfJxIjRLDe2Vsv34eQw8h+rzEsvVeM0faFFc4eS1ZHcSQ== X-Received: by 2002:a5d:6f19:0:b0:21a:3802:8b5b with SMTP id ay25-20020a5d6f19000000b0021a38028b5bmr15816875wrb.391.1655646033792; Sun, 19 Jun 2022 06:40:33 -0700 (PDT) Received: from paquerette (176-136-230-16.abo.bbox.fr. [176.136.230.16]) by smtp.gmail.com with ESMTPSA id eh1-20020a05600c61c100b003973d425a7fsm13356009wmb.41.2022.06.19.06.40.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Jun 2022 06:40:32 -0700 (PDT) From: Edouard Debry To: Tim Cross Cc: emacs-orgmode@gnu.org Subject: Re: Orgmode plain list bullet : change automatically with list depth References: <87wndiv988.fsf@localhost> <87edznjyji.fsf@localhost> <87iloyree8.fsf@gmail.com> Date: Sun, 19 Jun 2022 15:40:32 +0200 In-Reply-To: <87iloyree8.fsf@gmail.com> (Tim Cross's message of "Sat, 18 Jun 2022 10:17:40 +1000") Message-ID: <86wndc93fz.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::431; envelope-from=edouard.debry@gmail.com; helo=mail-wr1-x431.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, 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" 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=1655646093; 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=h6N0cIOvaQS9eCGf5m/zBZRpyUneeHpTQOf2Jyh2v3w=; b=f7KF/28hHyWlACWHlRHqNyPbhNrV/VrwzetqTGVvo3WDZFWsu9vvPLx46ddtMMSC23zMuh CE+cfA0iTze4vYDxtKYFNPcRXfZtXnkYb9RFBNvOvJ8ptINyOj3f/KZiT/VguuZcze+QWv wGeYUS7V+d6RafDlSA2vloCq1N5v4VNcweXL6wiLUjDZfUfjproDWdaqqE1lVP8o+e4+d7 prlY31fCQy9HhTK5II1y6qJV3feuKNOzz74SYVVDnHhvnTkjLO8Hev8TVJKlnxe9F0GhPf 1VqK9d+Q91CQerqdJy5WjAAURZaTuL2SVHHH+R5axTUBGSL5z5JVzr+WwUsleQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1655646093; a=rsa-sha256; cv=none; b=ElHTqzyy1L8cIdgM4SKfr9VNQN+0NvK739Ino8nh6Z/7EJ7xE/3lk7ywRKuwHWBnw9PE2l tp8dQ6Yx9fd+VWCpHpmg4Y8naJTLZQP8G70tjB8pXx4np9V6Bp0od5Nibh07tyv3B8Q2s8 vcUPn3npkR/dh8GAHiTTtgpGK9INe8Efp42WROrjjjJxrLpElRUWaqlOv2npgyGF64g/K+ 2wH7/uht0Oo9fD8yIYPwc6VArYX7aiBEIqQSm8pf02zTdqLy8M4hVCDW4ZEKSp6VSjYdBv EWZvBETsZZ1Kh2yi4fS7WjWkE9Y/3Uy90fmqxlOjK/0m1gh+rWj75VfKMrnPMQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="Ut/mGCOm"; 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" X-Migadu-Spam-Score: -2.48 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="Ut/mGCOm"; 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" X-Migadu-Queue-Id: 97B271236D X-Spam-Score: -2.48 X-Migadu-Scanner: scn1.migadu.com X-TUID: PqWII0Fw5+vf Are you sure bullet lists are irrelevant to org ? I tried without success to make a list without "-" or "+" in my *scratch*. Regards Tim Cross writes: > Samuel Wales writes: > >> sure. >> >> iiuc i think op wants 2 things: >> >> 1] graphical bullets. i.e. not the - + etc. that are in the org >> plain text as saved to disk. >> 2] each level of a list to have the same bullet style >> >> >> examples of 2]: >> >> a conforming list: >> >> - this is level 1. for this list, we always want level 1 to >> use the - bullet style in the org plain text. >> + this is level 2. for this list, we always want level 2 >> to use the + bullet style in the org plain text. >> + another level 2 >> - another level 1 >> + another level 2 >> + the + is CONSISTENT with the + in the level 2 of the >> previous list item >> >> >> a non-conforming list: >> >> >> - this is level 1. for this list, we always want level 1 to >> use the - bullet style in the org plain text. >> + this is level 2. for this list, we always want level 2 >> to use the + bullet style in the org plain text. >> + another level 2 >> - another level 1 >> * another level 2 >> * these * markers are INCONSISTENT with the + markers in >> the level 2 previous list item. >> >> >> the idea is for org [as opposed to fontification] to enforce this >> level correspondence. whenever we do a bullet style change at any >> level, org could change ALL BULLETS AT THE SAME LEVEL. this keeps the >> list conforming. >> >> currently, org does not do this. instead, it allows you to >> say that /demotion/ makes a + when you have a -. but >> without enforcement, the list can quickly become >> non-conforming after the user edits it. >> >> this idea is independent (orthogonal) to fontification / >> displayed graphical glyph. i think op's 2] idea can make >> sense. and then fontification / displayed graphical glyph >> can be done perhaps with a fontification package. >> >> in any case, fontification can merely say that + looks >> like =F0=9F=98=BA or so. orthogonal to levels. >> >> > > Sorry, but I think this idea is misguided.=20 > > The 'bullets' in lists are largely irrelevant to org. Lists are > determined by the indentation level. I don't think org actually cares > about wither an item starts with '-', '+', or '*'. I also don't think it > matters (from an org perspective) if a list has a mix of different > bullets. This might be 'offensive' for users, but is largely irrelevant > for org.=20 > > This means the questions now becomes "Do we add the additional complexity > and possible performance hit to enforce bullet consistency?" and "Are > there any use cases where people might want different bullets at the > same level in a list?".=20 > > As having mixed bullets does not impact on org export, I'm inclined to > leave this as a user issue i.e. if you want things to be consistent, > then be consistent. The current behaviour I think is pretty good i.e. if > you start using a different bullet, new items at the same level will use > that bullet and when you shift an item to be at the parent level, it > will change the bullet to be the same as the parents. If you indent an > item, it will use the same bullet as the parent, but you can change it > and then all additional items at that level will use the same bullet.=20 > > As the bullet type has no baring on org's processing of lists, I think > this is a purely presentation issue and therefore anything we want to do > wrt enforcement should in fact occur at the font-lock layer. e.g. allow > code which will just set the bullet to some preferred mapping based on > level. As the user won't see which 'real' character is being used, it > won't matter if it uses mixed bullet styles. This also has the advantage > that the user can just use the one bullet 'type' and see different > bullet rendering based on level, so you won't have any 'inconsistency' > anyway as all entries just use the same bullet.=20