From: Ihor Radchenko <yantar92@posteo.net>
To: "Juan Manuel Macías" <maciaschain@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 13:00:51 +0000 [thread overview]
Message-ID: <8734uwjerg.fsf@localhost> (raw)
In-Reply-To: <87il3tax9a.fsf@posteo.net>
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> May it be better to use something like
>>
>> \newcommand\nothing{}
>> \newcommand{\safenewline}{\\\nothing}
>>
>> And then use \safenewline instead of \\[0pt]
>>
>> In my tests,
>>
>> \begin{center}
>> \begin{tabular}{ll}
>> [t] & s\safenewline
>> [I] & A\safenewline
>> [m] & kg\safenewline
>> \end{tabular}
>> \end{center}
>>
>> Does not suffer from misinterpreting new line as argument.
>
> I remember the thread where these issues were discussed and the long
> discussion where many alternatives were proposed. After all, the \\[0pt]
> solution still seems the safest to me. It seems that the problem is
> located only in the verse environment, probably due to some particular
> redefinition of the \\ macro that makes that environment.
We chose \\[0pt] simply because we did not find anything better.
In fact, Max expressed some concerns about \\[0pt] - in
https://list.orgmode.org/orgmode/tik0uf$td1$1@ciao.gmane.io/ and
https://list.orgmode.org/orgmode/tio0th$vn8$1@ciao.gmane.io/
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.
> 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 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.
>> We may as well strip the trailing \\[0pt] there.
>
> I think it would be best to remove the last \\[0pt] in the verse block.
> I can prepare a patch, but I'm afraid that org-latex-verse-block is
> becoming an homage to replace-regexp-in-string...
Not a big deal. Or, if you want, you can make changes via temporary
buffer; if that is cleaner.
--
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>
next prev parent reply other threads:[~2024-01-17 12:59 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 [this message]
2024-01-17 15:58 ` Max Nikulin
2024-01-17 17:50 ` Juan Manuel Macías
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8734uwjerg.fsf@localhost \
--to=yantar92@posteo.net \
--cc=emacs-orgmode@gnu.org \
--cc=maciaschain@posteo.net \
--cc=manikulin@gmail.com \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.