emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Juan Manuel Macías" <maciaschain@posteo.net>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: Daniel Fleischer <danflscr@gmail.com>,
	 Max Nikulin <manikulin@gmail.com>,
	 emacs-orgmode@gnu.org
Subject: Re: Line breaks and brackets in LaTeX export
Date: Mon, 17 Oct 2022 11:30:25 +0000	[thread overview]
Message-ID: <8735bmelgu.fsf@posteo.net> (raw)
In-Reply-To: <87edv6izx4.fsf@localhost> (Ihor Radchenko's message of "Mon, 17 Oct 2022 09:04:39 +0000")

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 


  reply	other threads:[~2022-10-17 11:37 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-15 21:35 [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX Juan Manuel Macías
2022-10-16  3:24 ` Ihor Radchenko
2022-10-16 12:08   ` Juan Manuel Macías
2022-10-16 15:04 ` Max Nikulin
2022-10-16 16:33   ` Verse block and separations (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX) Juan Manuel Macías
2022-10-17  8:54     ` Ihor Radchenko
2022-10-18  9:39       ` Verse block and separations Juan Manuel Macías
2022-10-17 14:48     ` Verse block and separations (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX) Max Nikulin
2022-10-19 11:08     ` Max Nikulin
2022-10-19 11:24       ` Verse block and separations Juan Manuel Macías
2022-10-16 17:14   ` Line breaks and brackets in LaTeX export (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX) Juan Manuel Macías
2022-10-17  9:04     ` Ihor Radchenko
2022-10-17 11:30       ` Juan Manuel Macías [this message]
2022-10-17 11:47         ` Line breaks and brackets in LaTeX export Ihor Radchenko
2022-10-17 12:27           ` Juan Manuel Macías
2022-10-17 15:01         ` Juan Manuel Macías
2022-10-17 16:46           ` Max Nikulin
2022-10-17 18:04             ` Juan Manuel Macías
2022-10-18  4:41               ` Ihor Radchenko
2022-10-18 14:23                 ` Juan Manuel Macías
2022-10-19  3:57                   ` Ihor Radchenko
2022-10-19  5:11                     ` Max Nikulin
2022-10-19 11:16                       ` Juan Manuel Macías
2022-10-19 12:30                         ` Juan Manuel Macías
2022-10-19 17:07                           ` Max Nikulin
2022-10-20 16:55                             ` Juan Manuel Macías
2022-10-21  3:34                               ` Ihor Radchenko
2022-10-21 16:38                                 ` Max Nikulin
2022-10-21 19:32                                   ` Juan Manuel Macías
     [not found]                         ` <ac290c60-3b54-5521-eb16-82e6611dc6e2@gmail.com>
2022-10-20 17:07                           ` Juan Manuel Macías
2022-10-29  2:36                     ` Ihor Radchenko
2022-11-13 17:01                       ` Max Nikulin
2022-10-18  4:39             ` Ihor Radchenko
2022-10-19 17:12               ` Max Nikulin
2022-10-20  5:07                 ` Ihor Radchenko
2022-10-20 17:15                   ` Max Nikulin
2022-10-21  3:41                     ` Ihor Radchenko
2022-10-21 16:32                       ` Max Nikulin
2022-10-22  5:15                         ` Ihor Radchenko
2022-10-22 12:26                           ` Juan Manuel Macías
2022-10-22 15:55                           ` Max Nikulin
2022-11-01  1:51                             ` Ihor Radchenko
2022-11-01 16:07                               ` Max Nikulin
2022-11-02  6:44                                 ` Ihor Radchenko
2022-11-02  6:46                                   ` Ihor Radchenko
2022-11-02 15:27                                     ` Max Nikulin
2022-11-03  6:15                                       ` Ihor Radchenko
2022-11-03 15:00                                         ` Juan Manuel Macías
2022-11-03 15:33                                           ` Max Nikulin
2022-11-03 15:48                                             ` Juan Manuel Macías
2022-11-04  4:23                                             ` Ihor Radchenko
2022-11-04  5:40                                               ` Max Nikulin
2022-11-05  5:30                                                 ` Ihor Radchenko
  -- strict thread matches above, loose matches on Subject: below --
2022-11-01 16:55 Juan Manuel Macías

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8735bmelgu.fsf@posteo.net \
    --to=maciaschain@posteo.net \
    --cc=danflscr@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=manikulin@gmail.com \
    --cc=yantar92@posteo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).