Re: Trailing whitespace after export snippets without a transcoder

[Ihor Radchenko <yantar92@posteo.net>]

Max Nikulin <manikulin@gmail.com> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>