From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id 6DlmLFFV4GQmOAEASxT56A (envelope-from ) for ; Sat, 19 Aug 2023 07:38:25 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id iH5yLFFV4GSFQwAAauVa8A (envelope-from ) for ; Sat, 19 Aug 2023 07:38:25 +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 205144F742 for ; Sat, 19 Aug 2023 07:38:24 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=fizz.buzz header.s=fm3 header.b=hCbnm32g; dkim=fail ("headers rsa verify failed") header.d=messagingengine.com header.s=fm1 header.b=HTkNQ2nK; 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=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1692423505; a=rsa-sha256; cv=none; b=YFI75OjKjgvSOxImer5RMy020k+ftgIqX2RqcYT5hCD1bZDAinZgsdVTOODEeFtTMoMr3y nx+XiTaYv24RYZsVrs8Lb8v5aBz7ATLNfuVqUhoRIbk19Q38g5hqC7bWNBNYZFfIj8apJ/ Q8lXwRTOmyfOPcME7vGxG7bEqVbsM9jc6aH5E+7Hceg9xjY3Sqli+ERQoHAs+25hk/M7O/ ZiCYKrBYmnvRQvlVqrqtpfGEMlnEceO3BBqhGKNLBnto+GwfdHRd4N/lFYm/Yo/4XawYgW OkVHL3DFBp+bcua3L7LXVdPu/KhrsVfgNvWevccwsgrptkn9aYm+49g9ncxROg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=fizz.buzz header.s=fm3 header.b=hCbnm32g; dkim=fail ("headers rsa verify failed") header.d=messagingengine.com header.s=fm1 header.b=HTkNQ2nK; 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=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1692423505; 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:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=zeXtvtEBzYqj3+H4XwpG2FDMP3AyLJXPDRx2FITuw+c=; b=NjC9NULXO1w3wm/R9A4mqyjUzlCmLpecLOg7Z5fCtTXRiyPcxiAicxvBbxQMlDpBNUztTp Ijrr8ADZ5cS59yj7rsTkxuKcmc+vBPNmT4Em8Y01JEUpl0sfMohg6lysxOUTUz8ihoioaU HrIvnvcA/ALhaqc0l3pvGWuSULbp+9oJ+9TBVJOxArTh3Pi2UhGvrT2y5Qlhgb5fqsRSjU Lg3rlHAFBZiCeE3aBFzUoKYeJS7CScpZQnNucnvBLZRyITVi+35z4rP1mBFczt12LE3nQ6 uerN6Bnue2aJM/6ZqgEnPRKgJxfPXcPJftBpIYkZT/67AqHwa/k9X9vcNSZtsg== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qXEZV-0007oF-D2; Sat, 19 Aug 2023 01:32:25 -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 1qXEZM-0007k3-Jh for emacs-orgmode@gnu.org; Sat, 19 Aug 2023 01:32:17 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qXEZJ-0007K1-Py for emacs-orgmode@gnu.org; Sat, 19 Aug 2023 01:32:16 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 4DB995C00D8 for ; Sat, 19 Aug 2023 01:32:08 -0400 (EDT) Received: from imap47 ([10.202.2.97]) by compute6.internal (MEProxy); Sat, 19 Aug 2023 01:32:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fizz.buzz; h=cc :content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:sender:subject:subject:to:to; s=fm3; t=1692423128; x=1692509528; bh=zeXtvtEBzYqj3+H4XwpG2FDMP 3AyLJXPDRx2FITuw+c=; b=hCbnm32gQkPUrSwR/4lpONf0ZeTihGNHcIEqgcRjP PWNiYbriLw0IxSWWH/agAdkygAcqhJs+hIpASaTf1kzAbCYGSYWZU3gVhPduihk5 Tv1FP5GbFbOAaM7tyW0Rj92+6qrvoVgFemVbkBDNAaKJ3o5LIXKe/eoD8HVSrgTS /dqi0JzkEAofa6OsI2K+9kW+X5bU11LuRdW17ZWfuz5y1yS/aqpVL4tGc/uOI5Mn D/IRFOoNs7SCOpd1Nvx8XDr91DHxLHjpIkNxCKkoKUS5kzv2jqaG32agBGo31d+Z xCU1ZDRWCYKad9Iwf2O4T5XEg1DXKH0mX/DSv7/xRZjsg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1692423128; x=1692509528; bh=zeXtvtEBzYqj3+H4XwpG2FDMP3AyLJXPDRx 2FITuw+c=; b=HTkNQ2nKIFUpJpZoxKxruZlAKmpd4NbKtYUldPPZHzu6KhLVfD3 thVbBSfz7glX8vy4mqOg83qqf0evUU3jn/m/P+WnKg2Yd7nZ/dx+K3I9Ar91iEut TGpHKKnsOnkf/oOcfyd/ltJB+8CJZdX3BLiE57BNlgNXRRi8B5BmWIpSj/E+DYtU S5QOSsAZuxFw+ly4lyxsiRO9wjZmZqU2hwsBEJMNyb+5G7MDE1HHslG4Zrj325wI PXc06Gq6zYG+jD/xVkYbUl7sUssVx1wluxSLzmmyadx5N9x2WBiSh0ktpnx6TjQZ LzW4IYDx3urni7GEGHKq4b1pnDyuUhanAxQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedruddugedgledvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsehttdertd erredtnecuhfhrohhmpedfvfhomhcutehlvgigrghnuggvrhdfuceothhomhesfhhiiiii rdgsuhiiiieqnecuggftrfgrthhtvghrnhepheffudeludfhfeffueejveevtdffudfhve eugfekjefgleefvefhheefudduteehnecuffhomhgrihhnpehgihhthhhusgdrtghomhdp phhlrghinhhlihhsthhofihnvghrshhhihhpnhhothgvshdrohhrghenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehtohhmsehfihiiiidrsghu iiii X-ME-Proxy: Feedback-ID: i589b4368:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0614FA60077; Sat, 19 Aug 2023 01:32:07 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-624-g7714e4406d-fm-20230801.001-g7714e440 Mime-Version: 1.0 Message-Id: <9372527e-3852-419e-936a-7b4dd38cc847@app.fastmail.com> Date: Sat, 19 Aug 2023 01:30:25 -0400 From: "Tom Alexander" To: emacs-orgmode@gnu.org Subject: Clarification on blank lines following list items Content-Type: text/plain Received-SPF: pass client-ip=66.111.4.26; envelope-from=tom@fizz.buzz; helo=out2-smtp.messagingengine.com X-Spam_score_int: -7 X-Spam_score: -0.8 X-Spam_bar: / X-Spam_report: (-0.8 / 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, FROM_SUSPICIOUS_NTLD=0.001, FROM_SUSPICIOUS_NTLD_FP=1.999, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_PDS_OTHER_BAD_TLD=0.01 autolearn=no 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-Scanner: mx0.migadu.com X-Spam-Score: -4.79 X-Migadu-Queue-Id: 205144F742 X-Migadu-Spam-Score: -4.79 X-TUID: q+eXvWAuJFbj 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. In a previous email the incredibly helpful Ihor Radchenko expanded on this further with: > Also, in addition to list items, footnote-definitions do not extend their contents to the trailing blank lines. which, I would interpret as the list items do not own their trailing blank lines but rather the list owns them. But that is not the behavior I am seeing. If I had to summarize the behavior I am seeing into words it would be: > List items own their trailing blank lines unless they are both the final list item and not the final element of a non-final list item. Below I have how I reached this conclusion, but before diving into the weeds I want to point two things out: 1. I have hastily thrown together a tool to help rapidly visualize the ownership of nodes in org-mode's AST. Before this tool, I was manually running org-element-parse-buffer and using M-g c to jump around to the various indices to see where nodes started/ended. With this tool, I can paste in my org-mode source and get a tree showing the contents of each node and I can click on the nodes to highlight the relevant characters in the org-mode source. It is available at https://github.com/tomalexander/org_mode_ast_investigation_tool . 2. I have flattened my analysis for plain-text consumption over email below, but if you'd prefer the original org-mode version of this investigation it is available at https://github.com/tomalexander/org_mode_ast_investigation_tool/blob/cba1d1e988be230f3104f5f63dfaeaaf5cd0d280/notes/plain_list_ownership_notes.org . And now, here is how I reached that conclusion: *** Test case 1 ``` 1. foo 1. bar 2. baz 2. lorem ipsum ``` | Plain List *Item* | Owns trailing blank lines | |------------------------+---------------------------| | foo (includes bar baz) | Yes | | bar | Yes | | baz | Yes | | lorem | No | In this test case, we see that the only list item that doesn't own its trailing blank lines is "lorem", the final list item of the outer-most list. *** Test case 2 We add "cat" as a paragraph at the end of foo which makes "baz" lose its trailing blank lines ``` 1. foo 1. bar 2. baz cat 2. lorem ipsum ``` | Plain List *Item* | Owns trailing blank lines | |-------------------------------+---------------------------| | foo -> cat (includes bar baz) | Yes | | bar | Yes | | baz | No | | lorem | No | In isolation, this implies that the final plain list item does not own its trailing blank lines, which conflicts with "baz" from test 1. New theory: List items own their trailing blank lines unless they are both the final list item and not the final element of a list item. Adding why to the table: | Plain List *Item* | Owns trailing blank lines | Why | |-------------------------------+---------------------------+-----------------------------------------------------------| | foo -> cat (includes bar baz) | Yes | Not the final list item | | bar | Yes | Not the final list item | | baz | No | Final item of bar->baz and not the final element of "foo" | | lorem | No | Final item of foo->lorem and not contained in a list item | *** Test case 3 So if that theory is true, taking the entire (foo -> lorem) list from test 1 and nesting it inside a list should coerce "lorem" to own its trailing blank lines since it would then be a final list item (of foo -> lorem) and the final element of the new list. ``` 1. cat 1. foo 1. bar 2. baz 2. lorem ipsum ``` | Plain List *Item* | Owns trailing blank lines | |-----------------------------+---------------------------| | cat (includes foo -> lorem) | No | | foo (includes bar baz) | Yes | | bar | Yes | | baz | Yes | | lorem | No | Against expectations, we did not coerce lorem to consume its trailing blank lines. What is different between "baz" and "lorem"? Well, "baz" is contained within "foo" which has a "lorem" after it, whereas "lorem" is contained within "cat" which does not have any list items after it. New theory: List items own their trailing blank lines unless they are both the final list item and not the final element of a non-final list item. | Plain List *Item* | Owns trailing blank lines | Why | |-----------------------------+---------------------------+------------------------------------------------------| | cat (includes foo -> lorem) | No | Final list item and not contained in a list item | | foo (includes bar baz) | Yes | Not the final list item | | bar | Yes | Not the final list item | | baz | Yes | Final element of non-final list item | | lorem | No | Final list item and final element of final list item | *** Test case 4 So if that theory is true, then we should be able to coerce lorem to consume its trailing blank lines by adding a second item to the cat list. ``` 1. cat 1. foo 1. bar 2. baz 2. lorem 2. dog ipsum ``` | Plain List *Item* | Owns trailing blank lines | |-----------------------------+---------------------------| | cat (includes foo -> lorem) | Yes | | foo (includes bar baz) | Yes | | bar | Yes | | baz | Yes | | lorem | Yes | | dog | No | For the first time our expectations were met! Enduring theory: List items own their trailing blank lines unless they are both the final list item and not the final element of a non-final list item. | Plain List *Item* | Owns trailing blank lines | Why | |-----------------------------+---------------------------+--------------------------------------------------| | cat (includes foo -> lorem) | Yes | Not the final list item | | foo (includes bar baz) | Yes | Not the final list item | | bar | Yes | Not the final list item | | baz | Yes | Final element of non-final list item | | lorem | Yes | Final element of non-final list item | | dog | No | Final list item and not contained in a list item | -- Tom Alexander