[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Merging paragraphs separated by comment lines during export (was: About

From: Ihor Radchenko
Subject: Merging paragraphs separated by comment lines during export (was: About 'inline special blocks')
Date: Thu, 26 May 2022 10:54:34 +0800

Max Nikulin <manikulin@gmail.com> writes:

>> First line
>> # comment
>> Second line
>> Should we consider a comment as inline object? I suspect that such
>> change will cause unpredictable breakages all around Org and third-party
>> packages.
> I believed that comments are stripped before passing to export backend, 
> so I did not expect any problem with inline comments.

You are right. After examining org-export--skip-p and
org-export--prune-tree, I see that all the comments are removed
unconditionally. But then, all we need to do is simply merging
paragraphs separated by a comment with :post-blank = 0 and the first
paragraph having :post-blank = 0. As long as export is concerned it is
simply a question of writing an export filter (Timothy, did you have
anything other than export in mind?)

>>> ---- >8 ----
>>> #+macro: nofollow [[attr:(:html (:rel "nofollow noopener"))]]
>>> An {{{nofollow}}[[attr:(:html (:title "be
>>> careful!"))]][[http://unsafe.com][unsafe link]].
>>> ---- 8< ----
>> I am not sure if I like this idea. It seems fine, but I afraid that it
>> will complicate parser at some point. We may want to assign such inline
>> properties to the following object, which is already a pain for
>> affiliated keywords.
> Certainly parser should recognize inline attributes, but I do not expect 
> real complications here. Assigning attributes may be performed when AST 
> is ready. Just collect attributes and put them to the following 
> non-attribute object during breadth-first tree transversal. Attributes 
> as the last child is a reason for a warning.

I was mostly thinking about element cache. Dealing with affiliated
keywords caused a lot of pain when I was working on cache. On the other
hand, inline objects are currently parsed together - org-element-context
always parses everything starting from the parent object
:contents-begin. So, maybe it is not going to be as much problem as I

Another concern about inline attributes is plain-text objects. Consider
the following paragraph:

Some text *bold* plain text. _Underline {{{attribute}}} more text
/italics/ end of underline_.

The object structure will be:
  (plain-text "Some text ")
    (plain-text "bold"))
  (plain-text " plain text. ")
    (plain-text "Underline ")
    (plain-text " more text ")
      (plain-text "italics"))
    (plain-text " end of underline"))
  (plain-text ".\n"))

So, should the attribute be assigned to " more text "? Just the next
word? What if we have something like

Text {{{attribute to be assigned to "two words"}}}two words but
plain-text element still continues.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]