Re: Line breaks and brackets in LaTeX export

[Juan Manuel Macías]

Ihor Radchenko writes:

> I see no issue with defcustom in general, but can you explain what
> practical problems it is going to solve? I am not talking about
> aesthetics of the exported LaTeX.

In my opinion it is not so much a question of aesthetics as of (let's
say) a certain conformity with what a LaTeX document should be. I think,
for example, in the case of a user who must submit his/her work in LaTeX
format to a publication, following the rules of that publication. It is
one thing for a LaTeX document to compile without error and quite
another for a LaTeX document to be or not to be formed according to good
practice. Would there be a problem sharing LaTeX documents with
unnecessary commands like \empty after all occurrences of \\?

Anyway. As for the compilation, it is highly unlikely that \empty will
cause any unexpected error. But LaTeX and its over 6000 packages is
unpredictable. It also seemed unlikely that \relax would cause any
problems, and catching up on the last discussion, it had to be replaced
by \empty because it returned an error just before \hline. \relax is one
of the recommended solutions from LaTeX, because it tells LaTeX that the
previous macro has finished expanding, but it is recommended keeping in
mind that the user will apply it only when needed, not everywhere. And
before \hline it doesn't make sense because there will never be an
'\\[...]' error. So, in the current situation, we can ask ourselves: is
\empty everywhere safe? Everything points to yes. Can we be 100% sure?
...?

The only thing I can think of, for a non-selective solution like the
current one, is the following: if \\ has an optional argument that must
be a length, then let's give it, but with a value of zero: \\[0pt], which
is equivalent to putting the value by default (zero) explicitly.

>> This is an example I came up with of how it could be fixed selectively
>> in LaTeX (big, big caveat: it's just a proof of concept and likely to
>> produce errors in other contexts. I think if a LaTeX package to fix this
>> isn't already out, it is either because the problem is very rare and the
>> solution for particular cases is known, or because there are drawbacks
>> inherent to LaTeX that I can't figure out right now):
>>
>> \makeatletter
>>
>> \def\my@protectlbrack{
>>   \@ifnextchar{[}{\relax}{}
>>   \@ifnextchar{*}{\relax}{}
>> }
>>
>> \let\old@break\\
>> \def\\{%
>>   \old@break\my@protectlbrack}
>>
>> %% for tables
>>
>> \let\old@tabularcr\@tabularcr
>> \def\@tabularcr{%
>>   \old@tabularcr\my@protectlbrack}
>>
>> % for use the old commands
>>
>> \newcommand\oldbreak{\old@break}
>> \newcommand\oldbreakt{\old@tabularcr}
>>
>> \makeatother
>>
>> \begin{document}
>>
>> lorem\\
>> [ipsum]
>>
>> lorem\\
>> *ipsum
>>
>> \begin{tabular}{cccc}
>> a & a & a & a \\
>> [a] & a & a & a \\
>> *a & a & a & a \\
>> \end{tabular}
>>
>>
>> \end{document}
>
> Won't it make it impossible to use
> @@latex:\\@@
> @@latex:[1em]@@
>
> deliberately?

What I've done in this code is redefine \\ so that if the next character
is a [ or a * it doesn't do anything. To use the macro with the old
behavior, you would have to use the new macros \oldbreak and \oldbreakt
(this one for tables):

@@latex:\oldbreak@@
@@latex:[1em]@@

Anyway, like I said, it's a proof of concept. In the tests I've done it
works very well, but on a large scale I can't be sure of the results.

Best regards,

Juan Manuel