From: "Juan Manuel Macías" <maciaschain@posteo.net>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: orgmode <emacs-orgmode@gnu.org>, Max Nikulin <manikulin@gmail.com>
Subject: Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
Date: Wed, 17 Jan 2024 17:50:52 +0000 [thread overview]
Message-ID: <87o7dju9vn.fsf@posteo.net> (raw)
In-Reply-To: <8734uwjerg.fsf@localhost> (Ihor Radchenko's message of "Wed, 17 Jan 2024 13:00:51 +0000")
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
next prev parent reply other threads:[~2024-01-17 17:51 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-02 23:46 [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export Juan Manuel Macías
2024-01-13 15:08 ` Ihor Radchenko
2024-01-13 16:05 ` Juan Manuel Macías
2024-01-13 18:28 ` Ihor Radchenko
2024-01-13 20:22 ` Juan Manuel Macías
2024-01-14 12:33 ` Ihor Radchenko
2024-01-14 21:58 ` Juan Manuel Macías
2024-01-16 14:09 ` Ihor Radchenko
2024-01-16 19:33 ` Juan Manuel Macías
2024-01-17 13:00 ` Ihor Radchenko
2024-01-17 15:58 ` Max Nikulin
2024-01-17 17:50 ` Juan Manuel Macías [this message]
2024-01-18 13:05 ` Ihor Radchenko
2024-01-19 17:28 ` Juan Manuel Macías
2024-01-20 12:34 ` Ihor Radchenko
2024-01-20 13:22 ` Juan Manuel Macías
2024-01-20 13:46 ` Ihor Radchenko
2024-01-20 15:41 ` Juan Manuel Macías
2024-01-20 18:47 ` Ihor Radchenko
2024-01-20 20:27 ` Juan Manuel Macías
2024-01-21 13:42 ` Ihor Radchenko
2024-01-21 19:25 ` Juan Manuel Macías
2024-01-31 11:39 ` Ihor Radchenko
2024-01-21 6:06 ` Max Nikulin
2024-01-20 10:09 ` Max Nikulin
2024-01-20 10:57 ` Juan Manuel Macías
2024-01-20 12:41 ` Ihor Radchenko
2024-01-21 5:56 ` Max Nikulin
2024-01-20 10:27 ` Max Nikulin
2024-01-20 12:35 ` Ihor Radchenko
2024-01-21 5:44 ` Max Nikulin
2024-01-31 15:09 ` Ihor Radchenko
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=87o7dju9vn.fsf@posteo.net \
--to=maciaschain@posteo.net \
--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).