From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id IG2LI9YwLmYSpgAA62LTzQ:P1 (envelope-from ) for ; Sun, 28 Apr 2024 13:19:50 +0200 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id IG2LI9YwLmYSpgAA62LTzQ (envelope-from ) for ; Sun, 28 Apr 2024 13:19:50 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=S1Zmp+Gr; dmarc=pass (policy=none) header.from=posteo.net; 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-Seal: i=1; s=key1; d=yhetil.org; t=1714303190; a=rsa-sha256; cv=none; b=S4KkjRcUh2BERpu6rwcNhwgAeUFMjv6zZFLnaa2DCaRSTbMXpvp9cQJdmKwQ4GT695N1lA xgut3x7W/n4ai/niK7ZyjUm/T6vi3tn+fB2xrlcPnCru3YLt9eFxYUvKKj16ltUV0R4Ga0 Ewc3TW9hJoDliQA+jyNh6NiVWPhL84qVtyzdWLph5nHJfex2vJsMVoYr7bTJ6Ef+QZ+07E 321qQntdxD+lUKUR720RHh7AC+Si061cjphdmpHq+0qoBWtsBC/uY/AdzK5glHodfMLx0N UbG6D4tzYTK+3fNpvugR/ZVsgk36szoYguFuHbHP5lJsqJvn9MwxiTOSxHw2vA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=S1Zmp+Gr; dmarc=pass (policy=none) header.from=posteo.net; 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=1714303190; 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=YqqNUkOYF2F6IjNM/sVaYqYOttK65YXIug0J8bTHoF0=; b=GVQJpUZwtNZuVn3Npblb57TvrbYmYvcup8SihJFX6gddgwRHGAk7g+pTglhzea/oaYVb5C O7ML+CWait+corffXirJDwct0EfWM27I9eoTJ4jYTOpS/BtRxl8DmQokAh0ikaWu88MKlY vOAKV7ot6CLFgu+FolvDV+7yEoAL7qwXX9GTyabCvvjlSl7EGgLVTHvAw8D0vsstJeCgXA IuJTsjakhAKH8UANkywUjoJsPt+2aKhvWnTKWGMy9nS4+LycTRy49bl1Ux0rKnUI0QGoWl nMNDMvLcS6NflLsX2FieeIHgaUFUIO8Ix9NPsI2Oj2XS17hHm1nTsMezCjY/Sw== 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 67BA61AFEC for ; Sun, 28 Apr 2024 13:19:50 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s12Yj-0008Ek-30; Sun, 28 Apr 2024 07:19:06 -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 1s12Yg-0008ER-VD for emacs-orgmode@gnu.org; Sun, 28 Apr 2024 07:19:03 -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 1s12Ye-0001q0-O5 for emacs-orgmode@gnu.org; Sun, 28 Apr 2024 07:19:02 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 10E1E240028 for ; Sun, 28 Apr 2024 13:18:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1714303138; bh=Q997yDPtnMSEh5AOChPt01ZN4pBAuaPM6ZhJ3nvfMTE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=S1Zmp+GrRJUp/GpmaJPJQxqnGwnS8LDcJpwEGN2ljCTtO3r1ODqAS8knmAxKsQxRz /nlIXUrGs+QwFymdkis00I5B2r6Qp+bKH6DlrDujr/tIpTzf9qzLDCRUzGt+tdlMNq fOY/CR92MorQMJadmJPPJfLHwcWuMSZQl+nqP/utp4LdALhvzb/A2J9orgRFq3b0hX e9ZukVi1YjvkjZZzh6ncXA0vMIFckOdcA8csoSq7T9SwwJvkw9sJquNXRnxe+w2+7P sD4qevMxXrkN1MWHhL0AfRXeKvKgD89YJQ/jKJXkPxPz+vqU8Jw2KJdbbdGReYj9Kh stMGhdVByZdmg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4VS3r11L1xz6txZ; Sun, 28 Apr 2024 13:18:57 +0200 (CEST) From: Ihor Radchenko To: Max Nikulin Cc: emacs-orgmode@gnu.org Subject: Re: Trailing whitespace after export snippets without a transcoder In-Reply-To: References: <5210ac1c-ed73-4b82-a296-41cf90b9f0a7@gmail.com> <87jzvmwnmw.fsf@localhost> <87ilauagvy.fsf@localhost> <87y1hqqgiu.fsf@localhost> <87ttk26crq.fsf@localhost> <87h6fwmgkm.fsf@localhost> <87wmoqq3ad.fsf@localhost> <87wmoprzm4.fsf@localhost> Date: Sun, 28 Apr 2024 11:19:58 +0000 Message-ID: <871q6ploo1.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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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-Queue-Id: 67BA61AFEC X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -9.51 X-Spam-Score: -9.51 X-TUID: he4aymn6y7Fl Max Nikulin writes: > On 23/04/2024 02:01, Ihor Radchenko wrote: >> For example, consider an HTML exporter that aligns tags nicely and >> keeps blank lines between markup blocks for readability. If we >> remove such blank lines unconditionally, it will be problematic. > > I consider that just newlines are enough to make HTML markup human > readable. I believe blank lines appear in HTML due to conditional > constructs interpreted by various template engines and almost nobody > cares concerning actual formatting in such cases. I looked further, and it turns out that Org export is already overriding the blank lines produced by the exporters. In particular, we have ((memq type '(nil org-data plain-text raw)) results) ;; Append the same white space between elements or objects ;; as in the original buffer, and call appropriate filters. (t (org-export-filter-apply-functions (plist-get info (intern (format ":filter-%s" type))) (let ((blank (or (org-element-post-blank data) 0))) (if (eq (org-element-class data parent) 'object) (concat results (make-string blank ?\s)) (concat (org-element-normalize-string results) (make-string blank ?\n)))) info)) For now, we only override newlines between elements, not objects. For objects (but not plain-text), we unconditionally append :post-blank. I conclude that it is actually OK to go a step further and cleanup newlines after objects, before appending the post-blank. Same for plain-text. >> I guess that I can change the condition to not include trailing space >> from (rx whitespace eol) to (rx (any " \t|) eol). > > One more time I forgot that neither \n nor non-breakable space are > included into post-blank. > I think, more permissive regexp may be used. At least it should accept > newlines and any space after it > > (rx (any " \t" eol) (zero-or-more whitespace) eos) I see how special case for \n is useful. Not should about non-breakable space. > Moreover, post-blank of the pruned object may be ignored when the > following element starts with spaces other than purely zero width ones. This can never happen, AFAIK. All the spaces after any object become a part of its :post-blank attribute. > My feeling is that extensive test suite is required. It would be easier > to review what cases are not handled yet. May you summarize various examples that should be considered? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at