Max Nikulin <> writes:

> Concerning element vs. exported text, consider a derived backend that 
> ignores italics markers if a paragraph has some attribute. Usually
>       Paragraph \\
>       \emph{[something]}
> does not cause any problem, however if italics is ignored it is an error
>       Paragraph\\
>       [something]
> That is why namely exported code of adjacent leaf node should be 
> examined. Ideally there should be a possibility to add some attributes 
> or properties to distinguish raw export snippet.

This is a valid example.

> Unfortunately it requires complete redesign of org-export.

Thinking about it more, we may actually do post-processing of the
exported text. Unless I miss something, constructs like "\\[0pt]\n" can
_always_ be replaced with "\\\n" as long as the next line does not match
"^[ \t]*\\[". Even when such construct is deliberately placed by the
user. There will be no difference in the generated pdf.

Or, to be completely safe, we can introduce a defcustom that will
control such clean-up (clean up by default).

I propose the following:
1. Merge my patch with \\[0pt] safe page breaks
2. Modify org-latex-template to replace unnecessary occurrences of
   "\\[0pt]" in CONTENTS when org-latex-compact-latex (you may propose
   other defcustom names) is non-nil.


Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <>.
Support Org development at <>,
or support my work at <>

Reply via email to