Re: Line breaks and brackets in LaTeX export

[Ihor Radchenko <yantar92@posteo.net>]

Max Nikulin <manikulin@gmail.com> writes:

>>> Selectively adding some workaround require complete reimplementation of
>>> exporters. I have some curiosity concerning pandoc approach, but I am
>>> unsure if I will reserve some time to read its code.
>> 
>> Maybe or maybe not. We have org-export-get-next-element and a number of
>> exporters doing something special for the first/last object inside a
>> container.
>
> I have an impression that markup generated by children often added using 
> %s to some other construct. I may be wrong.

You are right, but missing subtle detail.
Export transcoders for container elements are called with 3 arguments:
data, contents, and info.

DATA contains the actual AST of the transcoded element, including its
children available via org-element-contents. CONTENTS is the string
representations of the exported children elements. Before CONTENTS is
generated, relevant transcoders are also called for each child of the
DATA.

When transcoding children (e.g. table rows), the sibling rows can always
be accessed using org-export-get-previous-element and
org-export-get-next-element.

>>> An idea how to avoid complete redesign: at first add something like
>>>      %__ORG_PROTECT_NEWLINE__
>>> after each \\, later at an optimizing pass remove the comment if next
>>> line does not start from a star or a square bracket, otherwise use some
>>> workaround, e.g. "{[}". \relax may be suitable as well (in the beginning
>>> of rows, not after \\).
>> 
>> I am not sure if it is a good idea. It may interfere with export filters.
>
> I do not expect negative effect from a comment added at the end of line. 
> Optimizing pass may be performed prior to user filters.

Filters are applied by ox.el immediately after transcoding each element.
See the final expressions in org-export-data. The filters may alter the
exported string, including removing the %__ORG_PROTECT_NEWLINE__ we put
there. Of course, we can warn users about this particular caveat, but I
do not like such design -- it is too fragile.

> As another approach text properties may be used as a communication 
> channel unless they are stripped by ox.

I am not sure what you are referring to. If modifying exported string,
it will suffer from the same problems as your idea with comment.

-- 
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>