[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
thought.
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:
(paragraph
(plain-text "Some text ")
(bold
(plain-text "bold"))
(plain-text " plain text. ")
(underline
(plain-text "Underline ")
(attribute)
(plain-text " more text ")
(italics
(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.
Best,
Ihor
- About opening issues vs email [Was: About 'inline special blocks'], (continued)
- Re: About 'inline special blocks', Juan Manuel Macías, 2022/05/25
- Re: About 'inline special blocks', Timothy, 2022/05/23
- Re: About 'inline special blocks', Eric S Fraga, 2022/05/24
- Re: About 'inline special blocks', Christian Moe, 2022/05/26
- Re: About 'inline special blocks', Max Nikulin, 2022/05/24
- Re: About 'inline special blocks', Ihor Radchenko, 2022/05/25
- Re: About 'inline special blocks', Max Nikulin, 2022/05/25
- Merging paragraphs separated by comment lines during export (was: About 'inline special blocks'),
Ihor Radchenko <=