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 ne
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 ma
Max Nikulin writes:
>> I do not think that we need to handle this Org mode-wide (it will be
>> difficult and will likely cause breaking changes).
>
> I have not figured out why it may become a breaking changes and what
> backends need blank lines inside paragraph. I would make stripping empty
>
On 21/04/2024 20:00, Ihor Radchenko wrote:
Max Nikulin writes:
A space@@ascii:*@@ character.
Hmm. We actually have a similar scenario in `org-export--prune-tree'
with a slightly different logic - only keep spaces when previous object
does not have any.
I like this idea. At first I even
Max Nikulin writes:
>> I have no clue about the rationale of this special behaviour - it dates
>> back to the days when Org export was merged. It is also not documented
>> anywhere, AFAIK.
>
> I would not expect that the space after the following export snippet is
> ignored in the case of ox-htm
On 20/04/2024 18:14, Ihor Radchenko wrote:
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a6d9fd82e
Back-end developers should pay attention to the fact that white spaces
before and after an ignored export snippet now are accumulated in the
output.
I have no clue
Max Nikulin writes:
>> +#+begin_src org
>> +The following line may become a patagraph separator.
>> +@@comment: might give unexpected effect @@
>> +Put some text before @@comment: a better variant
>> +@@ and after instread.
>> +#+end_src
>>
>> I am no longer able to repro
