Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export

[Juan Manuel Macías]

Ihor Radchenko writes:


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

I find several drawbacks to adding a new latex command like \nothing.
First, the standardization of the exported LaTeX code is lost. \\[0pt],
at least, always compiles. A new command obviously needs to be defined
first. Let's imagine that someone wants to simply share the LaTeX code
of a table... Then there is the problem of how to name the new command
so that it doesn't 'clash' with some user-defined command. In LaTeX it
is usually good practice to use the at sign character (@) in the name of
a command or macro that is not in user space, since this character can
only be used in a *.sty file. In a *.tex file, if you want to use the at
sign to define or redefine something, you have to enclose the code
between \makeatletter...\makeatother. And, in any case, I think that the
LaTeX code produced by org should be as 'universal' as possible (standard
LaTeX code + packages included in TeX live), and leave the definition of
new commands or environments to the user's discretion.

On the other hand, we are not sure that a command like \nothing does not
have some undesirable effect. I seem to remember that in the
aforementioned thread, adding \relax (the typical command that is used
to tell LaTeX do nothing) was also proposed as a solution, and it was
discarded for some reason.

>> 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 see. I think pandoc's solution is what Leslie Lamport recommends
(naturally, Lamport doesn't say to enclose /all/ brackets in curly
braces).

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

In principle, any environment that takes an optional argument in a
"dangerous" position. Just do a simple test. Something like this:

#+begin_figure
[lorem] ipsum
#+end_figure

will throw an error like ''LaTeX Error: Unknown float option...''

Of course, putting an empty line after #+begin... usually solves it. But
the user may not know it.

There are also a number of commands with an optional argument. For
example \pagebreak. Something like this will give an error:

lorem @@latex:\pagebreak@@ [ipsum]

\item is another typical example, but in this case org adds \relax.

Best regards,

Juan Manuel