From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id oHC2Gpo2KmawZQEAe85BDQ:P1 (envelope-from ) for ; Thu, 25 Apr 2024 12:55:22 +0200 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id oHC2Gpo2KmawZQEAe85BDQ (envelope-from ) for ; Thu, 25 Apr 2024 12:55:22 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=none; 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=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1714042522; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=PXW/p4NYLb6Cj3S1k93NCH17iZlnaCTC9ydlyxyTZP4=; b=J8vXF6eU4rKwTJBp5xHcZqO0mr6CIA3WuTLEe3YVm4bv2fgzKEl9Otsy+EDfE1P1MOGToH JleB9mjtU1Bhx5pCYmGwnslMjU8+iaVUEky+eyDUsvyntJ4H6W5Lvn/rtzIvVbaPiCRleq L701Aff1OlJMFjj3SFhqlYcne5KzsD66/XMCkKgL+wYt+gAfOzG2RE2am2IjS3Hf4gw/11 igRbqRg3CPJAfZMSlvZ0Ak7u+JLpu4IWBYaUFIy8Y8U7bxOo5lQFIesWEzSFM0cKg6sPN0 DfmtIF2C/tPwqmckYIX5vGHewbYvIj6LMK+KS6bVhWWec9PQLK+LxL+KCKx6kw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1714042522; a=rsa-sha256; cv=none; b=qeneKtbmAh2Jugb0N29czfFsA5o87917hyEtZNZBrfddz2+FXyTHqk27ZJjUYpu7PlqHQv c5ABBmz83L8OkJcpHh5yIE3CMswUcJ1LP0zkwmFCR/ma6DiWcNtVAoOOGyXUUzzig64rUF JYOpaf+onFLcLfvxt74X1QkHUjiP+K3ih4Z2Mfb91FE8ZOZQ6YEbnsqezRQCQFEJAmfIKd zUDHCPDRLeTh1Yf59doHLoZwq2ugHha70k644TdQngbnknGniixI5c4n3DphDeDfc8ETfu SVV+Qv65QHoUBkzS0wx2zqQxa3ZS53A6zbwrr7onv3Y9AKQmTYJHLT9CxOFCOQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; 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=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none) 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 DA9E61746C for ; Thu, 25 Apr 2024 12:55:21 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rzwkM-0004Fv-0l; Thu, 25 Apr 2024 06:54:35 -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 1rzwkI-0004E3-2e for emacs-orgmode@gnu.org; Thu, 25 Apr 2024 06:54:30 -0400 Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rzwkD-0003qo-VH for emacs-orgmode@gnu.org; Thu, 25 Apr 2024 06:54:27 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1rzwkB-0004jI-S1 for emacs-orgmode@gnu.org; Thu, 25 Apr 2024 12:54:23 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: Trailing whitespace after export snippets without a transcoder Date: Thu, 25 Apr 2024 17:54:17 +0700 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla Thunderbird Content-Language: en-US, ru-RU In-Reply-To: <87wmoprzm4.fsf@localhost> Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 26 X-Spam_score: 2.6 X-Spam_bar: ++ X-Spam_report: (2.6 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -3.49 X-Spam-Score: -3.49 X-Migadu-Queue-Id: DA9E61746C X-Migadu-Scanner: mx13.migadu.com X-TUID: S8sNNH1E9Vel 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. However I proposed to make this feature an option that is turned on by default. > 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) Moreover, post-blank of the pruned object may be ignored when the following element starts with spaces other than purely zero width ones. In my opinion, keeping extra spaces (e.g. post-blank ones from pruned objects) makes less harm than aggressively stripping them. Anyway some backends must normalize spaces (while for others they do not matter). While newline characters are not affected, this part of change does not affect accidental split of paragraphs. My feeling is that extensive test suite is required. It would be easier to review what cases are not handled yet.