Juan Manuel Macías <maciasch...@posteo.net> writes: >> May it be better to use something like >> >> \newcommand\nothing{} >> \newcommand{\safenewline}{\\\nothing} >> >> And then use \safenewline instead of \\[0pt] >> >> In my tests, >> >> \begin{center} >> \begin{tabular}{ll} >> [t] & s\safenewline >> [I] & A\safenewline >> [m] & kg\safenewline >> \end{tabular} >> \end{center} >> >> Does not suffer from misinterpreting new line as argument. > > I remember the thread where these issues were discussed and the long > discussion where many alternatives were proposed. After all, the \\[0pt] > solution still seems the safest to me. It seems that the problem is > located only in the verse environment, probably due to some particular > redefinition of the \\ macro that makes that environment.
We chose \\[0pt] simply because we did not find anything better. In fact, Max expressed some concerns about \\[0pt] - in https://list.orgmode.org/orgmode/tik0uf$td1$1...@ciao.gmane.io/ and https://list.orgmode.org/orgmode/tio0th$vn8$1...@ciao.gmane.io/ If the idea with custom command does not have obvious downsides, it might be a better option. In the previous thread, we only considered redefining \\ itself - obviously a non-starter for environments that re-define \\ by their own, like here. > In any case, square brackets are a problematic character in LaTeX > (think, e.g., of some environment that takes an optional argument). I > think pandoc chooses to always export them as {[}{]}: > > #+begin_src sh :results latex > str="[hello world] [foo] [bar]" > pandoc -f org -t latex <<< $str > #+end_src > > #+RESULTS: > #+begin_export latex > {[}hello world{]} {[}foo{]} {[}bar{]} > #+end_export > > We could do the same, but I'm afraid it's too late if > org-latex-line-break-safe already exists... I don't remember if > something similar was proposed in that discussion, and it was rejected > for some reason. It is not too late. AFAIR, we just decided not to dig deeper about pandoc's approach. As for {[}{]}, it is a bit difficult to implement. Especially when we also consider user filters and derived backends. If we have several transcoders of consequent elements, there is always a risk that even when a given filter/transcoder is generating a valid LaTeX code, concatenating them may still cause issues like we have with \\. I am wondering if there are other examples of commands with optional arguments that may cause a similar problem with \command [unrelated text] If there are, we may actually want to consider pandoc's approach seriously. >> We may as well strip the trailing \\[0pt] there. > > I think it would be best to remove the last \\[0pt] in the verse block. > I can prepare a patch, but I'm afraid that org-latex-verse-block is > becoming an homage to replace-regexp-in-string... Not a big deal. Or, if you want, you can make changes via temporary buffer; if that is cleaner. -- 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>