emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Line breaks and brackets in LaTeX export


From: Ihor Radchenko
Subject: Re: Line breaks and brackets in LaTeX export
Date: Mon, 17 Oct 2022 11:47:38 +0000

Juan Manuel Macías <maciaschain@posteo.net> writes:

> 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 \\?

I haven't seen any publication rule that prevents using valid LaTeX
commands like this. Do you have concrete examples? If not, one could
argue that any auto-generated output could break some imaginary rule.

I am also wondering how LaTeX documents generated from LyX or TeXmacs
look like. Are they not using some obvious machine-generated constructs?

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

My answer is: "\\" is 100% not universally safe. Simply because we have
that bug report with [ ... ] items in tables.
So, anything with no concrete counter-example is better as long as we
are reasonably sure that we are not breaking LaTeX conventions.

> 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 has been proposed and then rejected by Max in
https://list.orgmode.org/orgmode/ti5tdb$rd2$1@ciao.gmane.io/ and he
concluded that some side effects are present when using \\[0pt]:

Max>       \\[0pt]
Max> 
Max> causes insertion of some code for negative vertical skip (of zero height 
Max> this case). It should not be really harmful, but I would avoid this hack.

> 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]@@

It means that LaTeX packages that redefine \\ may be affected. I'd
prefer to avoid such side effects.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]