From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id UJ24E23ri2dSCwAAqHPOHw:P1 (envelope-from ) for ; Sat, 18 Jan 2025 17:57:01 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id UJ24E23ri2dSCwAAqHPOHw (envelope-from ) for ; Sat, 18 Jan 2025 18:57:01 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=bqeCfRwM; 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=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1737223021; 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:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=w21oWCi6Lo0jh+3A2RDzfZNe9zRu96nVxheU6DEA4ug=; b=kBRg84QY29Zj0KcP06SI5p23V8idueJ9dqWXanDS2Kk5CYH/G1KyEBdkat7cf90wQWqp3n ngQttDy6RZOPMPHBd13zgfcYK0tpy2DZB4Abn0JpNxk2jgUAU9pyD0MXrFjUz1Al6DtsTC Kj9XpyJNgsD9ZZNzqw2ZiWgvzY+yv6DzzKAOxvnxyJtW8My8EaXprESATBJ3opcWE16FNs HKyf2JqgIFTDMIdYR8a0WcXRn8eKv0LDeWQJqfmMk3i3MMan39bDxNQaTFI0JsFb1HUo1n 4bQ5L3V3RLDz/LZ2i15n0MluMjc5t526zZzslFnV3yMSdjP32UQgHF1kVUGSCw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=bqeCfRwM; 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=gmail.com ARC-Seal: i=1; s=key1; d=yhetil.org; t=1737223021; a=rsa-sha256; cv=none; b=kM/EwPEqONcm2CFzD38cLbfoOXki9h5lVHT8xthqE1uhKN7WonQrcE132vARJebtMvR+MN FEgXtg77+iOpatK9eDZrYyHxW0Av3myTKqHOxy/GrvAYtUHMxSxBlHpwEn4u2h/P6Gzbrj 2puLIPsgdU8DgUcdURbr83faP7RADNrdDGxU2AgoJZvm0IWD9XWFDkgM7fBt9VuZoRRv/3 WnvVXD1j/UkkaysWisD3/56rWldMd45KXELech8trehULZPFN4L6B+suVKSsARSw0aFfPo dBKXxR4KW+GntXwmgpsr58y7NQXw/oUmkGErYqogE9zwB2vuj/FhaImMkizCDw== 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 081D096A68 for ; Sat, 18 Jan 2025 18:57:01 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tZD3B-0006Rn-6e; Sat, 18 Jan 2025 12:56:01 -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 1tZD39-0006Ra-Sy for emacs-orgmode@gnu.org; Sat, 18 Jan 2025 12:55:59 -0500 Received: from mail-ej1-x629.google.com ([2a00:1450:4864:20::629]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tZD37-0000T9-VN for emacs-orgmode@gnu.org; Sat, 18 Jan 2025 12:55:59 -0500 Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-ab2bb0822a4so626138366b.3 for ; Sat, 18 Jan 2025 09:55:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1737222956; x=1737827756; darn=gnu.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=w21oWCi6Lo0jh+3A2RDzfZNe9zRu96nVxheU6DEA4ug=; b=bqeCfRwMhvnjTLvFCwoSqcZKWYPFGU349YI0ZadI+GdIWmap3jlXCnMIxZEL/GCiLv yQN3J05fU6OSLYxv7ocJM34D62CPWXEVfOFhka/VoaMyjE/YOsswkEpmITk6by0BuGid ghqux4LMZ7fC5L8df6Fjn91vYpyBtR+aUFLoJLVt/AuKF+srY6xXE9RmpneuwGJfwXLu rx5lXBMKaIiuTc20msUEBJ9x4vUMARRLFipYv/j51Lbsprzv7y9keL1aoJCDtEMh1Ggb qM8JBLT5bbrZjSYL4fmMORB2fsgcLbXRAhdclIAXePagyYttTwz2QV98PA9O7E8tSx0C 048w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737222956; x=1737827756; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=w21oWCi6Lo0jh+3A2RDzfZNe9zRu96nVxheU6DEA4ug=; b=LTVvaWQfPZqyYtiWX4hGW4/iLP5p8D0wyn2bs3kJn8J5tVDd2DIldt3rVxKy5RWHI1 ZoRY7gpjYeWsdRJxAHu4NWGIMOIUw+VnYb4d0YK0fnmuM6801fEpjrIZVaNXTfoHfm+/ BHxy0xGA/LI8RagtENrl6eYTtgqdmAp9BMzZapZeWTUS6V5DQhxAFq43YybFvE4JdImz s+boQtNaeVtt/aRxNjcKiCiIUTSa9sC7OLwB/hb4047QfKe90r0JpQEueaLogOPDF62r VlJJEeXgKyPcwRFkxINcKZoFAvZSaIF8yBjZP5JxPRoFYeTv17sew0Y8c8bjeM2uBn2J h2tg== X-Gm-Message-State: AOJu0YwwKtig+CWFirdg2IVdWbnalHUJT/3uqNWGIBb0gGJ5llQEGy/d FVM2WrSIz5NGrP/f4ajxBHEnwwEwP+/VdSyoRPBwFt1nBuzuucBtaSU90g== X-Gm-Gg: ASbGncv781ms7NdDcYSK7NXJRVya9SPVP3hRHZPCSg3Zrvc5v0gBkWndm/r8L21CH2T vCkG2Pky6HNrSdxepJnD5Fajn0uwO1RBbfv3IP3L6SdG/e3Lv2MC3OidkasK5ocf/dbc+saKiD3 O5BimIbtX8yB9AqgOcBv/lA2XRAbRayCa0V1pIqiw852tXP03Zc+f4igEFC7AXEHF1DS1recpkz PNrnQTcbmc9vWcHyVnIphpJl+I/Z23Q66lTceEYDRK8kPsWEDRuuUK2cGBv8rZUgVQHBUICxyU3 J/D8SXPzA2N7rQkJRvmdAV6gHcKQrcGKM6OT52ip9eGXzKoLptBl0OIzkZjb0NggWw== X-Google-Smtp-Source: AGHT+IHiwCkd6AedP6Vh2j+XoIEaExbiMwDasUqBiG4vWYbObhfLsuiDISBB3OVh1C+ToczOl7duBw== X-Received: by 2002:a17:907:72c1:b0:ab3:61e8:aa16 with SMTP id a640c23a62f3a-ab38b38134amr771139366b.43.1737222955775; Sat, 18 Jan 2025 09:55:55 -0800 (PST) Received: from nixos.localnet (2a01cb0801c53000f62679fffe69ff50.ipv6.abo.wanadoo.fr. [2a01:cb08:1c5:3000:f626:79ff:fe69:ff50]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5db736425adsm3287567a12.3.2025.01.18.09.55.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 18 Jan 2025 09:55:54 -0800 (PST) From: chris To: emacs-orgmode@gnu.org Cc: yantar92@posteo.net Subject: [BUG] org-element-interpret-data does not preserve blank lines after elements Date: Sat, 18 Jan 2025 17:55:52 +0000 Message-ID: <5871868.DvuYhMxLoT@nixos> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Received-SPF: pass client-ip=2a00:1450:4864:20::629; envelope-from=inkbottle007@gmail.com; helo=mail-ej1-x629.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -7.50 X-Spam-Score: -7.50 X-Migadu-Queue-Id: 081D096A68 X-Migadu-Scanner: mx10.migadu.com X-TUID: yV9N1aY0MaS4 Hello, ``` GNU Emacs 30.0.93 Org mode version 9.7.16 ``` I'm reporting a potential bug in the `org-element-interpret-data` function of Org mode. *Description:* When using `org-element-interpret-data` as the reciprocal of `org-element- parse-buffer`, I've noticed that blank lines before elements are preserved, but blank lines after elements are not. This behavior diverges from the expectation set by the Org Element API documentation. *Documentation Reference:* >From the [Org Element API documentation](https://orgmode.org/worg/dev/org-element-api.html#other-tools): > `org-element-interpret-data` is the reciprocal operation of `org-element- parse-buffer`. When provided an element, object, or even a full parse tree, it generates an equivalent string in Org syntax. > > More precisely, output is a normalized document: it preserves structure and blank spaces but it removes indentation and capitalize keywords. As a consequence, it is equivalent, but not equal, to the original document the AST comes from. *Steps to Reproduce:* Consider the following minimal example: ```emacs-lisp (let* ((hello-string-in "* hello how are you ** hello-world This is a programming section. ") (tree (with-temp-buffer (org-mode) (insert hello-string-in) (org-element-parse-buffer))) (hello-string-out (org-element-interpret-data tree))) hello-string-out) ``` *Expected Behavior:* The output (`hello-string-out`) should preserve the blank lines both before and after elements, matching the structure of the input string. *Actual Behavior:* The output is: ``` * hello how are you ** hello-world This is a programming section. ``` As shown, the blank lines after "how are you" are missing, while the blank lines before are preserved. *Use Case:* This behavior affects buffer-editing operations where transformations are made on the Abstract Syntax Tree (AST). For example, when uppercasing headline titles: ```emacs-lisp (let* ((hello-string-in "* hello how are you ** hello-world This is a programming section. ") (tree (with-temp-buffer (org-mode) (insert hello-string-in) (org-element-parse-buffer))) (_ (org-element-map tree 'headline (lambda (el) (let* ((title-data (org-element-property :title el)) (title-string (org-element-interpret-data title-data))) (org-element-put-property el :title (upcase title-string)))))) (hello-string-out (org-element-interpret-data tree))) hello-string-out) ``` The output is: ``` * HELLO how are you ** HELLO-WORLD This is a programming section. ``` Again, the blank lines after "how are you" are not preserved. *Additional Example:* Changing TODO keywords demonstrates the same issue: ```emacs-lisp (let* ((hello-string-in "\n\n* hello\n\nhow are you\n\n** hello-world\n\nThis is a programming section.\n") (tree (with-temp-buffer (org-mode) (insert hello-string-in) (org-element-parse-buffer))) (_ (org-element-map tree 'headline (lambda (h) (org-element-put-property h :todo-keyword "DONE")))) (hello-string-out (org-element-interpret-data tree))) hello-string-out) ``` The output is: ``` * DONE hello how are you ** DONE hello-world This is a programming section. ``` Despite the initial blank lines in the input, the output lacks the blank lines after elements. *Conclusion:* The issue seems to be that `org-element-interpret-data` does not preserve blank lines after elements, contrary to the expectation that it "preserves structure and blank spaces." This can hinder user experience when using these functions for buffer editing purposes, where maintaining the original document's spacing is important. Best, Chris