|
From: | Max Nikulin |
Subject: | Re: [PATCH v2] Re: [BUG] Tables with square brackets do not compile in PDF (latex) export [9.5 (release_9.5-59-g52e6f1 @ /home/sjt015/repo/emacs/lisp/org/)] |
Date: | Mon, 10 Oct 2022 23:30:04 +0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 |
On 08/10/2022 12:17, Ihor Radchenko wrote:
Max Nikulin writes:+(defconst org-latex-linebreak-safe "\\\\\\relax"Is there a reason why you did not add \n at the end? It could help to avoid a lot of `concat' calls.Mostly because there are a couple of places where we need the version without newline. I though that `concat' is better than `replace-regexp-in-string' or introducing two constants with/without newline. I guess, we can introduce the two constants. It might be slightly more optimal. See the updated version of the patch.
Reading with more attention, I do not think that second constant really makes the code more clear. I had a hope that it is enough to introduce a single constant, but it seems it is not the case. I did not expect that newline should not be added e.g. planning export handler. Perhaps it is better to commit v1.
- (equal "\\begin{tabular}{l}\n\\(x\\)\\\\\n\\end{tabular}" + (equal "\\begin{tabular}{l}\n\\(x\\)\\\\\\relax\n\\end{tabular}"May be left as is since the line next to \\ does not start from square brackets.Nope. It can't. These are ERT tests for the ox-latex output.
My bad. I am sorry.
@@ -2659,7 +2675,7 @@ ;;;; Line Break (defun org-latex-line-break (_line-break _contents _info) "Transcode a LINE-BREAK object from Org to LaTeX. CONTENTS is nil. INFO is a plist holding contextual information." - "\\\\\n") + org-latex-linebreak-safe-newline)
A minor naming inconsistency: "line-break" and "linebreak".
[Prev in Thread] | Current Thread | [Next in Thread] |