From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id kJUOJuaA4GSP1AAASxT56A (envelope-from ) for ; Sat, 19 Aug 2023 10:44:22 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id GF33JOaA4GTLfwAAG6o9tA (envelope-from ) for ; Sat, 19 Aug 2023 10:44:22 +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 C9D4841932 for ; Sat, 19 Aug 2023 10:44:21 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=ZZ3NbE+s; 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=1692434662; 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=Jgudta8n4inxVUOUrakYFjN0HRupGFhpIlzmSY/nKRo=; b=qhEoEg+tXQuzKO7laBx3RDNw8hpr4UlihyQPkRUZvn5bHIKANTwGrlm3U3pzq/jS5Fxzk+ vg00VixR5Zl9ZhP6BWa6YwKYEHKUv/PNqL5nxvCJsSq2oJUAV9IDV043hF8ilFZXYfHGjb HDGgzeaC65LOR6y+ucon3E9otP6b5n3+yjSc3bhCwfMsrrSBhAd7tppUIAzWNlPtSj/3wz SQ09hH7jF85v7L1qgk6rWQKQM4JV462R2cNAzNCKhQsfloXEniS3aTfSQ+QSIRnUih2w9A VMUOlR2498VV2M3fFh67Q326i4mHP5r8D3SwAuOL1Qnv10beVoIpamLGiNogFQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1692434662; a=rsa-sha256; cv=none; b=dQBv11i8jWJuJ7aOoPtH8UEgy5AQBDQlwPZltqD87UUKqTQlSSssiM1kE1vxwilCHtIy0t OzeYZf7tWGtCV5Yw3JbrpwvGJl+4ohjNI4BEbfSe27uo0y75QXnbDDZkCeWPETweGp2ISf VOlxNt5gDl84yzw6CfOzw3k4U540s/PEpW9eh4yiL+gLrNIj1gtujB9Uj/25i+S0P43HBw sNv2qecHd3G0mYqiyKyBSpHxHBE+59dhCLoWJR9Xun/OIWyDrbjiCkMJ9Grn1wgj0DnzoQ GxxFAQeYCDKlh69TIBkyQY+gY1S373A8wViDeQs40GQGxM4MvRv5RMxt+moSyg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=ZZ3NbE+s; 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 Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qXHYN-0000IV-UQ; Sat, 19 Aug 2023 04:43:27 -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 1qXHYM-0000IN-7X for emacs-orgmode@gnu.org; Sat, 19 Aug 2023 04:43:26 -0400 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 1qXHYJ-0000Yz-8p for emacs-orgmode@gnu.org; Sat, 19 Aug 2023 04:43:25 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 4BB73240029 for ; Sat, 19 Aug 2023 10:43:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1692434600; bh=xJ592tC8xRmhaHGdzU2dNdBx+1VgodXB6myCBFm7fns=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=ZZ3NbE+sZbKSyvkV/wumos056Q+1jDUNKWAbliKszeIDy8nRS+Kf6dObR1ltKaCgp tIAS3UZcSt7Aar3zGxqfYmsP7gFel368aU6QTJ1wYxel9o32ccVDDG3JjTfNMTjKQw pFlSZuEf7XtHZxcGQado6IsD7p1N8u4LlPleDygWIDJfWnjwyYdrapY9sNkMxs/gKj lziUqiHlg7JsaicsUABWaljBio0QsOgNt9LU1CxWat7WtkcgvHwx8meEHwSGUb8iXE ASElL7zB9NoMsBcOzJXBXMysTdNPlvySJWrQWk3vFzf+zqT9QDLsJG5xTDoRZx9i3Z /pj0N36AUJR1g== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RSXM21SYgz9rxH; Sat, 19 Aug 2023 10:43:09 +0200 (CEST) From: Ihor Radchenko To: Tom Alexander Cc: emacs-orgmode@gnu.org Subject: Re: Clarification on blank lines following list items In-Reply-To: <9372527e-3852-419e-936a-7b4dd38cc847@app.fastmail.com> References: <9372527e-3852-419e-936a-7b4dd38cc847@app.fastmail.com> Date: Sat, 19 Aug 2023 08:43:38 +0000 Message-ID: <87bkf3o211.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain 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_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -6.40 X-Spam-Score: -6.40 X-Migadu-Queue-Id: C9D4841932 X-Migadu-Scanner: mx1.migadu.com X-TUID: m6xKekjURVvK "Tom Alexander" writes: > I am noticing the list items have some very context-sensitive specific behavior regarding ownership of the trailing blank lines. I was hoping to get some clarification on this (namely, are my observations correct, am I stumbling across a bug, or have I not dug deep enough to suss out the real rules?). The org-mode documentation states: > >> With the exception of list items and footnote definitions blank lines belong to the preceding element with the narrowest possible scope > > but it does not state who ends up owning those blank lines. I can see how this explanation steered you into wrong line of thoughts. It should better be explained from the widest scope to the narrowest scope, not the opposite. Greater Org elements are generally represented by contents where child elements are located + markup defining the greater element itself + optional trailing blank lines. For example, drawers are :NAME: ... :END: Naturally, blank lines are the attribute of such drawer - they belong to it and are recorded as :post-blank property. The above works for many greater elements. However, it becomes a bit tricky when a greater element does not have any "end" delimiter: -------- - item Some text Or even :drawer: with text :end: Not an item. -------- Now, assigning contents vs. blank lines is not so obvious. We can either include these blank lines into contents or keep them separate within :post-blank property. Then, there are two kinds of greater elements that can end with blank lines without separator: 1. Elements where blank lines do not affect parsing (headlines) 2. Elements where trailing blank lines are syntactically meaningful and by themselves serve as a marker of element ending. - footnote-definition ends when Org see two consecutive blank lines or a heading or another footnote-definition. - plain-list also uses two consecutive blank lines as delimiter. In the second case, Org makes the plain-list/footnote-definition element "own" the blank lines (set :post-blank) instead of putting these blank lines inside contents. If we did otherwise, changes in contents could make the parent plain-list/footnote-definition invalid - if the double blank delimiter is edited away. ----- Further, there is a special case with greater elements without contents: * Heading with no contents * Another heading The first heading does not have contents, yet we want to record the fact that it has multiple blank lines before the next element - :post-blank here is set, unlike heading with contents. ----- Finally, :post-blank in items is special. Consider: - item 1 - item 2 - item 3 We do not treat blank between items as parts of their paragraphs historically. Also, it makes sense for such short items. (there are actually some reasons why we might want to alter this historical convention, but for now it is how it is) -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at