* [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export @ 2024-01-02 23:46 Juan Manuel Macías 2024-01-13 15:08 ` Ihor Radchenko 0 siblings, 1 reply; 32+ messages in thread From: Juan Manuel Macías @ 2024-01-02 23:46 UTC (permalink / raw) To: orgmode Hi, I recently discovered that if the last line of a LaTeX 'verse' environment ends in '\\[0pt]', the space after the environment is drastically altered. The space after a 'verse' environment (which is a modified list environment) must be equivalent to \partopsep+\topsep+\baselineskip. I have done the test with a document, defining a rectangle of that height with tikz, where you can see the difference in vertical space with and without '\\[0pt]': https://i.imgur.com/khbboDZ.png Naturally, this implies an issue when exporting the verse block to LaTeX, since the presence of the '\\[0pt]' string alters the expected result in the compiled PDF. My suggestion is that the last line of the verse block is not exported with either the string '[0pt]' or the line break mark '\\', since it makes no sense for that mark to be there: it is the end of a paragraph and the very end of the environment. Can anyone think of a possible scenario where removing the '\\[0pt]' in the last line would cause a problem? If not, I might send a patch in the next few days. (I'm afraid that going back to abusing replace-regexp-in-string. I can't think of any other more elegant solution...). Best regards, Juan Manuel -- Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 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-20 10:27 ` Max Nikulin 0 siblings, 2 replies; 32+ messages in thread From: Ihor Radchenko @ 2024-01-13 15:08 UTC (permalink / raw) To: Juan Manuel Macías; +Cc: orgmode Juan Manuel Macías <maciaschain@posteo.net> writes: > Can anyone think of a possible scenario where removing the '\\[0pt]' in > the last line would cause a problem? If not, I might send a patch in the > next few days. (I'm afraid that going back to abusing > replace-regexp-in-string. I can't think of any other more elegant > solution...). In such scenario, we may technically violate what users ask us to do: #+begin_verse I really want newline here\\ #+end_verse -- 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> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 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-20 10:27 ` Max Nikulin 1 sibling, 1 reply; 32+ messages in thread From: Juan Manuel Macías @ 2024-01-13 16:05 UTC (permalink / raw) To: Ihor Radchenko; +Cc: orgmode Ihor Radchenko writes: >> Can anyone think of a possible scenario where removing the '\\[0pt]' in >> the last line would cause a problem? If not, I might send a patch in the >> next few days. (I'm afraid that going back to abusing >> replace-regexp-in-string. I can't think of any other more elegant >> solution...). > > In such scenario, we may technically violate what users ask us to do: > > #+begin_verse > I really want newline here\\ > #+end_verse I'm not sure if users asked for that specifically. You want a new line when there is a new line. This makes sense: #+begin_verse I really want newline here\\ blah... #+end_verse This does not: #+begin_verse I really want newline here\\ #+end_verse For LaTeX it is the same as this: #+begin_verse I really want newline here #+end_verse But this specifically alters the expected result in LaTeX, modifying the space after the environment: #+begin_verse I really want newline here\\[0pt] #+end_verse What is the cause? I don't know. But it happens. Best regards, Juan Manuel ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 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 0 siblings, 1 reply; 32+ messages in thread From: Ihor Radchenko @ 2024-01-13 18:28 UTC (permalink / raw) To: Juan Manuel Macías; +Cc: orgmode Juan Manuel Macías <maciaschain@posteo.net> writes: >> In such scenario, we may technically violate what users ask us to do: >> >> #+begin_verse >> I really want newline here\\ >> #+end_verse > > I'm not sure if users asked for that specifically. > ... > This does not: > > #+begin_verse > I really want newline here\\ > #+end_verse I am not sure. What about #+begin_verse I really want newline here\\ #+end_verse This must not be indented. (Just trying to come up with valid uses of newline at the end of LaTeX environment) Although, the above causes Org export to fail... \begin{verse} This is test\\[0pt]\\[0pt] \end{verse} Paragraph. -- 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> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 2024-01-13 18:28 ` Ihor Radchenko @ 2024-01-13 20:22 ` Juan Manuel Macías 2024-01-14 12:33 ` Ihor Radchenko 0 siblings, 1 reply; 32+ messages in thread From: Juan Manuel Macías @ 2024-01-13 20:22 UTC (permalink / raw) To: Ihor Radchenko; +Cc: orgmode Ihor Radchenko writes: > Juan Manuel Macías <maciaschain@posteo.net> writes: > >>> In such scenario, we may technically violate what users ask us to do: >>> >>> #+begin_verse >>> I really want newline here\\ >>> #+end_verse >> >> I'm not sure if users asked for that specifically. >> ... >> This does not: >> >> #+begin_verse >> I really want newline here\\ >> #+end_verse > > I am not sure. > What about > > #+begin_verse > I really want newline here\\ > #+end_verse > > This must not be indented. If I'm not mistaken, in TeX '\\' can only be used in horizontal mode: that is, within a paragraph. At the end of an environment like verse (\end{verse}) you are forced to enter vertical mode, and a new paragraph starts. Doing something like this, for example, adds a new paragraph after the environment: \documentclass{article} \usepackage{lipsum} \begin{document} \begin{verse} Lorem ipsum dolor\\ \end{verse} \lipsum[1] \end{document} Even this one produces the same result: \documentclass{article} \usepackage{lipsum} \begin{document} \begin{verse} Lorem ipsum dolor\\ \end{verse}\lipsum[1] \end{document} If one wants, for example, that after a verse environment there is no vertical space or indentation, the only way to do it is by modifying, globally or locally (with another environment) the space after the environment and adding a \noindent to the following paragraph: \documentclass{article} \usepackage{lipsum} \setlength\partopsep{-\topsep}\addtolength\partopsep{0pt} \begin{document} \begin{verse} Lorem ipsum dolor\\ \end{verse} \noindent\lipsum[1] \end{document} (taking into account that within the verse environment there is also a left indentation that would also have to be modified). Therefore, I think that whether or not a verse environment ends with \\ is irrelevant to LaTeX. The problem is that when it ends with \\[0pt], for some reason that escapes me, the space after the environment is altered. Best regards, Juan Manuel ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 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 0 siblings, 1 reply; 32+ messages in thread From: Ihor Radchenko @ 2024-01-14 12:33 UTC (permalink / raw) To: Juan Manuel Macías; +Cc: orgmode Juan Manuel Macías <maciaschain@posteo.net> writes: > If I'm not mistaken, in TeX '\\' can only be used in horizontal mode: > that is, within a paragraph. At the end of an environment like verse > (\end{verse}) you are forced to enter vertical mode, and a new paragraph > starts. Is it true for any environment? Or just some? > Therefore, I think that whether or not a verse environment ends with \\ is > irrelevant to LaTeX. The problem is that when it ends with \\[0pt], for > some reason that escapes me, the space after the environment is altered. I see. Although, I am not 100% if it is something we have to deal with in Org mode. May it be better to report this as a bug to LaTeX devs? -- 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> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 2024-01-14 12:33 ` Ihor Radchenko @ 2024-01-14 21:58 ` Juan Manuel Macías 2024-01-16 14:09 ` Ihor Radchenko 0 siblings, 1 reply; 32+ messages in thread From: Juan Manuel Macías @ 2024-01-14 21:58 UTC (permalink / raw) To: Ihor Radchenko; +Cc: orgmode Ihor Radchenko writes: > Juan Manuel Macías <maciaschain@posteo.net> writes: > >> If I'm not mistaken, in TeX '\\' can only be used in horizontal mode: >> that is, within a paragraph. At the end of an environment like verse >> (\end{verse}) you are forced to enter vertical mode, and a new paragraph >> starts. > > Is it true for any environment? Or just some? In principle, nothing prevents one from defining an environment for use in horizontal mode (within the paragraph). E.g.: \newenvironment{foo}{\itshape}{} Lorem \begin{foo}ipsum\end{foo} dolor. But the usual thing is that the beginning/end of an environment changes to vertical mode, with \par or something more elaborate. >> Therefore, I think that whether or not a verse environment ends with \\ is >> irrelevant to LaTeX. The problem is that when it ends with \\[0pt], for >> some reason that escapes me, the space after the environment is altered. > > I see. Although, I am not 100% if it is something we have to deal with > in Org mode. May it be better to report this as a bug to LaTeX devs? hmm... I don't know if this should be considered a bug. We may think that \\[0pt] should never do anything, but we must keep in mind that the end of the verse environment is the end of a paragraph, and it changes to vertical mode. And the end of a paragraph is an illogical place to put that command. But it seems that it also alters things when it is at that point. Check out this reply from David Carlisle (https://tex.stackexchange.com/a/82666): #+begin_quote \\ at the end of a paragraph causes bad output with an empty, maximally under-full, box, and so you get a warning about badness 10000, the visual effect looks a bit like extra vertical space but it is not: it is an extra spurious line at the end of the paragraph, and for example it is not dropped at a page break and will break widow/club line calculations. #+end_quote If there are environments that redefine \\, such as verse or tabular, probably putting the optional argument of \\ with a value of 0pt at the end of verse alters the calculation of the normal space after the environment, making it shorter. I think that here we would not have a LaTeX bug, because the syntax of the verse environment itself says that the last line should not carry any \\ mark. At the end of the tables I have not noticed any side effects. But in the export of the verse block, I would be in favor of somehow eliminating that last \\[0pt]. Best regards, Juan Manuel ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 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 0 siblings, 1 reply; 32+ messages in thread From: Ihor Radchenko @ 2024-01-16 14:09 UTC (permalink / raw) To: Juan Manuel Macías; +Cc: orgmode Juan Manuel Macías <maciaschain@posteo.net> writes: >>> If I'm not mistaken, in TeX '\\' can only be used in horizontal mode: >>> that is, within a paragraph. At the end of an environment like verse >>> (\end{verse}) you are forced to enter vertical mode, and a new paragraph >>> starts. >> >> Is it true for any environment? Or just some? > > In principle, nothing prevents one from defining an environment for use > in horizontal mode (within the paragraph). E.g.: > ... > But the usual thing is that the beginning/end of an environment changes to > vertical mode, with \par or something more elaborate. This is annoying. ox-latex has some transcoders that unconditionally add \\ at the end: clocks and planning lines. If they happen to be at the end of an environment, it can be problematic. > hmm... I don't know if this should be considered a bug. We may think > that \\[0pt] should never do anything, but we must keep in mind that the > end of the verse environment is the end of a paragraph, and it changes > to vertical mode. And the end of a paragraph is an illogical place to > put that command. But it seems that it also alters things when it is at > that point. Check out this reply from David Carlisle > (https://tex.stackexchange.com/a/82666): The very reason we use \\[0pt] is because it supposed to prevent interpreting [...] at the new line/transcoded element as argument. You demonstrated that it is yet not always safe enough. 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. > If there are environments that redefine \\, such as verse or tabular, > probably putting the optional argument of \\ with a value of 0pt at the > end of verse alters the calculation of the normal space after the > environment, making it shorter. I think that here we would not have a > LaTeX bug, because the syntax of the verse environment itself says that > the last line should not carry any \\ mark. AFAIU, \safenewline should still use re-defined version of \\ according to the context. > At the end of the tables I have not noticed any side effects. But in the > export of the verse block, I would be in favor of somehow eliminating > that last \\[0pt]. `org-latex-verse-block' already has a giant regexp replacement: ;; In a verse environment, add a line break to each newline ;; character and change each white space at beginning of a line ;; into a normal space, calculated with `\fontdimen2\font'. One ;; or more blank lines between lines are exported as a single ;; blank line. If the `:lines' attribute is used, the last ;; verse of each stanza ends with the string `\\!', according to ;; the syntax of the `verse' package. The separation between ;; stanzas can be controlled with the length `\stanzaskip', of ;; the aforementioned package. If the `:literal' attribute is ;; used, all blank lines are preserved and exported as ;; `\vspace*{\baselineskip}', including the blank lines before ;; or after CONTENTS. We may as well strip the trailing \\[0pt] there. -- 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> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 2024-01-16 14:09 ` Ihor Radchenko @ 2024-01-16 19:33 ` Juan Manuel Macías 2024-01-17 13:00 ` Ihor Radchenko 0 siblings, 1 reply; 32+ messages in thread From: Juan Manuel Macías @ 2024-01-16 19:33 UTC (permalink / raw) To: Ihor Radchenko; +Cc: orgmode Ihor Radchenko writes: > The very reason we use \\[0pt] is because it supposed to prevent > interpreting [...] at the new line/transcoded element as argument. > > You demonstrated that it is yet not always safe enough. > > 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. 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. > `org-latex-verse-block' already has a giant regexp replacement: > > ;; In a verse environment, add a line break to each newline > ;; character and change each white space at beginning of a line > ;; into a normal space, calculated with `\fontdimen2\font'. One > ;; or more blank lines between lines are exported as a single > ;; blank line. If the `:lines' attribute is used, the last > ;; verse of each stanza ends with the string `\\!', according to > ;; the syntax of the `verse' package. The separation between > ;; stanzas can be controlled with the length `\stanzaskip', of > ;; the aforementioned package. If the `:literal' attribute is > ;; used, all blank lines are preserved and exported as > ;; `\vspace*{\baselineskip}', including the blank lines before > ;; or after CONTENTS. > > 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... Best regards, Juan Manuel ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 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 0 siblings, 2 replies; 32+ messages in thread From: Ihor Radchenko @ 2024-01-17 13:00 UTC (permalink / raw) To: Juan Manuel Macías; +Cc: orgmode, Max Nikulin 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> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 2024-01-17 13:00 ` Ihor Radchenko @ 2024-01-17 15:58 ` Max Nikulin 2024-01-17 17:50 ` Juan Manuel Macías 1 sibling, 0 replies; 32+ messages in thread From: Max Nikulin @ 2024-01-17 15:58 UTC (permalink / raw) To: Juan Manuel Macías; +Cc: orgmode On 17/01/2024 20:00, Ihor Radchenko wrote: >>> \newcommand\nothing{} >>> \newcommand{\safenewline}{\\\nothing} [...] >>> \begin{center} >>> \begin{tabular}{ll} >>> [t] & s\safenewline [...] > If the idea with custom command does not have obvious downsides It does for tabularray https://github.com/lvjr/tabularray/issues/328 due to a custom parser, but probably it is safe for verse. I think, it is necessary to wait a couple of years till the fix will propagate to all stable Linux distributions. Notice that an arbitrary custom command is not the same as \empty. \safenewline would require more tricks, even \nothing would need \NewTableCommand\nothing{} Max Nikulin. Re: Line breaks and brackets in LaTeX export. Fri, 21 Oct 2022 23:38:29 +0700. https://list.orgmode.org/tiuhu5$nlp$2@ciao.gmane.io or \begin{tblr}[expand=\nothing]{rl} Max Nikulin. Re: Line breaks and brackets in LaTeX export. Thu, 20 Oct 2022 00:07:54 +0700. https://list.orgmode.org/65a1c205-cd18-4abe-b36d-a93763d7f5e8@gmail.com As to verse, I believe, \\... should be added at the end, but if a user added it explicitly then it should not be stripped. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 2024-01-17 13:00 ` Ihor Radchenko 2024-01-17 15:58 ` Max Nikulin @ 2024-01-17 17:50 ` Juan Manuel Macías 2024-01-18 13:05 ` Ihor Radchenko 1 sibling, 1 reply; 32+ messages in thread From: Juan Manuel Macías @ 2024-01-17 17:50 UTC (permalink / raw) To: Ihor Radchenko; +Cc: orgmode, Max Nikulin 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 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 10:09 ` Max Nikulin 0 siblings, 2 replies; 32+ messages in thread From: Ihor Radchenko @ 2024-01-18 13:05 UTC (permalink / raw) To: Juan Manuel Macías; +Cc: orgmode, Max Nikulin [-- Attachment #1: Type: text/plain, Size: 1866 bytes --] Juan Manuel Macías <maciaschain@posteo.net> writes: >> 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). This turned out to be a lot easier than I thought. See the attached patch. >> \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. With the patch, I am getting the following: * This is test lorem @@latex:\pagebreak@@ [ipsum] #+begin_figure [lorem] figure #+end_figure | [foo] | 2 | | [bar] | 3 | - [bax] - [aur] exports to lorem \pagebreak {[}ipsum] \begin{figure} {[}lorem] figure \end{figure} \begin{center} \begin{tabular}{lr} {[}foo] & 2\\[0pt] {[}bar] & 3\\[0pt] \end{tabular} \end{center} \begin{itemize} \item {[}bax] \item {[}aur] \end{itemize} [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-ox-latex-Make-sure-that-text-is-not-misinterpreted-a.patch --] [-- Type: text/x-patch, Size: 2511 bytes --] From db3fa01d6f15b3d3f499f77e342a608a822029c8 Mon Sep 17 00:00:00 2001 Message-ID: <db3fa01d6f15b3d3f499f77e342a608a822029c8.1705583005.git.yantar92@posteo.net> From: Ihor Radchenko <yantar92@posteo.net> Date: Thu, 18 Jan 2024 14:01:32 +0100 Subject: [PATCH] ox-latex: Make sure that [text] is not misinterpreted as LaTeX argument * lisp/ox-latex.el (org-latex-plain-text): Protect plain text starting from [. It might be misinterpreted as optional command argument if previous exported fragment ends with a command accepting such. * testing/lisp/test-ox-latex.el (text-ox-latex/protect-square-brackets): Add new test. Link: https://orgmode.org/list/87o7dju9vn.fsf@posteo.net --- lisp/ox-latex.el | 9 +++++++++ testing/lisp/test-ox-latex.el | 23 +++++++++++++++++++++++ 2 files changed, 32 insertions(+) diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el index 432f09f4e..a3505c25f 100644 --- a/lisp/ox-latex.el +++ b/lisp/ox-latex.el @@ -3094,6 +3094,15 @@ (defun org-latex-plain-text (text info) "\\(?:[ \t]*\\\\\\\\\\)?[ \t]*\n" (concat org-latex-line-break-safe "\n") output nil t))) + ;; Protect [foo] at the beginning of lines / beginning of the + ;; plain-text object. This prevents LaTeX from unexpectedly + ;; interpreting @@latex:\pagebreak@@ [foo] as a command with + ;; optional argument. + (setq output (replace-regexp-in-string + (rx bol (0+ space) (group "[")) + "{[}" + output + nil nil 1)) ;; Return value. output)) diff --git a/testing/lisp/test-ox-latex.el b/testing/lisp/test-ox-latex.el index 41df1b823..237ad97ec 100644 --- a/testing/lisp/test-ox-latex.el +++ b/testing/lisp/test-ox-latex.el @@ -29,6 +29,29 @@ (unless (featurep 'ox-latex) \f +(ert-deftest text-ox-latex/protect-square-brackets () + "Test [foo] being interpreted as plain text even after LaTeX commands." + (org-test-with-exported-text + 'latex + "* This is test +lorem @@latex:\\pagebreak@@ [ipsum] + +#+begin_figure +[lorem] figure +#+end_figure + +| [foo] | 2 | +| [bar] | 3 | + +- [bax] +- [aur] +" + (goto-char (point-min)) + (should (search-forward "lorem \\pagebreak {[}ipsum]")) + (should (search-forward "{[}lorem] figure")) + (should (search-forward "{[}foo]")) + (should (search-forward "\\item {[}bax]")))) + (ert-deftest test-ox-latex/verse () "Test verse blocks." (org-test-with-exported-text -- 2.43.0 [-- Attachment #3: Type: text/plain, Size: 224 bytes --] -- 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> ^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 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 10:09 ` Max Nikulin 1 sibling, 1 reply; 32+ messages in thread From: Juan Manuel Macías @ 2024-01-19 17:28 UTC (permalink / raw) To: Ihor Radchenko; +Cc: orgmode, Max Nikulin Ihor Radchenko writes: > This turned out to be a lot easier than I thought. > See the attached patch. > >>> \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. > > With the patch, I am getting the following: > > * This is test > lorem @@latex:\pagebreak@@ [ipsum] > > #+begin_figure > [lorem] figure > #+end_figure > > | [foo] | 2 | > | [bar] | 3 | > > - [bax] > - [aur] > > exports to > > lorem \pagebreak {[}ipsum] > > \begin{figure} > {[}lorem] figure > \end{figure} > > \begin{center} > \begin{tabular}{lr} > {[}foo] & 2\\[0pt] > {[}bar] & 3\\[0pt] > \end{tabular} > \end{center} > > \begin{itemize} > \item {[}bax] > \item {[}aur] > \end{itemize} Great! Simple and effective. And more surgical than pandoc's global solution. But now a question arises... Your code clearly solves the problem that led to the declaration of org-latex-line-break-safe, without foreseeing any unwanted effects, since it is the solution that is usually recommended from LaTeX. So, if this code is included in Org, what is the future of org-latex-line-break-safe? Best regards, Juan Manuel ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 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 0 siblings, 1 reply; 32+ messages in thread From: Ihor Radchenko @ 2024-01-20 12:34 UTC (permalink / raw) To: Juan Manuel Macías; +Cc: orgmode, Max Nikulin Juan Manuel Macías <maciaschain@posteo.net> writes: >> \begin{itemize} >> \item {[}bax] >> \item {[}aur] >> \end{itemize} > > Great! Simple and effective. And more surgical than pandoc's global > solution. But now a question arises... Your code clearly solves the > problem that led to the declaration of org-latex-line-break-safe, > without foreseeing any unwanted effects, since it is the solution that > is usually recommended from LaTeX. So, if this code is included in Org, > what is the future of org-latex-line-break-safe? It is still useful in situations like Paragraph\\ #+begin_export latex [foo] #+end_export or Paragraph\\ @@latex:[foo]@@ My patch does not do anything about verbatim environments. We may remove the use of `org-latex-line-break-safe' from some places, but not all. -- 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> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 2024-01-20 12:34 ` Ihor Radchenko @ 2024-01-20 13:22 ` Juan Manuel Macías 2024-01-20 13:46 ` Ihor Radchenko 0 siblings, 1 reply; 32+ messages in thread From: Juan Manuel Macías @ 2024-01-20 13:22 UTC (permalink / raw) To: Ihor Radchenko; +Cc: orgmode, Max Nikulin Ihor Radchenko writes: > Juan Manuel Macías <maciaschain@posteo.net> writes: > >>> \begin{itemize} >>> \item {[}bax] >>> \item {[}aur] >>> \end{itemize} >> >> Great! Simple and effective. And more surgical than pandoc's global >> solution. But now a question arises... Your code clearly solves the >> problem that led to the declaration of org-latex-line-break-safe, >> without foreseeing any unwanted effects, since it is the solution that >> is usually recommended from LaTeX. So, if this code is included in Org, >> what is the future of org-latex-line-break-safe? > > It is still useful in situations like > > Paragraph\\ > > #+begin_export latex > [foo] > #+end_export > > or > > Paragraph\\ > @@latex:[foo]@@ But since in both cases it is literal LaTeX code, the correct thing would be for the user to be in charge of adding the curly braces to the square brackets. I mean in such scenario it is LaTeX code, not Org. Anyway, in both examples it does not make sense for LaTeX to end a paragraph with the \\ macro, which is why we commented in previous messages in the thread. The \\ macro is only used in horizontal mode; this macro does not add a new paragraph but rather a forced line break within the paragraph. Best regards, Juan Manuel ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 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 0 siblings, 1 reply; 32+ messages in thread From: Ihor Radchenko @ 2024-01-20 13:46 UTC (permalink / raw) To: Juan Manuel Macías; +Cc: orgmode, Max Nikulin Juan Manuel Macías <maciaschain@posteo.net> writes: >> Paragraph\\ >> @@latex:[foo]@@ > > But since in both cases it is literal LaTeX code, the correct thing > would be for the user to be in charge of adding the curly braces to the > square brackets. I mean in such scenario it is LaTeX code, not Org. Not really. Because we do not give guarantees about the details of LaTeX export, we should try hard to not break things that users may put into literal export snippets. > Anyway, in both examples it does not make sense for LaTeX to end a > paragraph with the \\ macro, which is why we commented in previous > messages in the thread. The \\ macro is only used in horizontal mode; > this macro does not add a new paragraph but rather a forced line break > within the paragraph. In the example with @@latex:[foo]@@, \\ is not at the end of a paragraph - it is inside paragraph. Another alternative could be modifying how inline latex snippet is exported, but that's worse IMHO - we should try hard not to touch what users tell Org to do explicitly. -- 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> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 2024-01-20 13:46 ` Ihor Radchenko @ 2024-01-20 15:41 ` Juan Manuel Macías 2024-01-20 18:47 ` Ihor Radchenko 0 siblings, 1 reply; 32+ messages in thread From: Juan Manuel Macías @ 2024-01-20 15:41 UTC (permalink / raw) To: Ihor Radchenko; +Cc: orgmode, Max Nikulin Ihor Radchenko writes: > Juan Manuel Macías <maciaschain@posteo.net> writes: > >>> Paragraph\\ >>> @@latex:[foo]@@ >> >> But since in both cases it is literal LaTeX code, the correct thing >> would be for the user to be in charge of adding the curly braces to the >> square brackets. I mean in such scenario it is LaTeX code, not Org. > > Not really. Because we do not give guarantees about the details of LaTeX > export, we should try hard to not break things that users may put into > literal export snippets. > >> Anyway, in both examples it does not make sense for LaTeX to end a >> paragraph with the \\ macro, which is why we commented in previous >> messages in the thread. The \\ macro is only used in horizontal mode; >> this macro does not add a new paragraph but rather a forced line break >> within the paragraph. > > In the example with @@latex:[foo]@@, \\ is not at the end of a paragraph > - it is inside paragraph. What I mean is that literal LaTeX code is LaTeX code, despite the redundancy. IMHO, Org's only duty in that case is to export such literal code as valid LaTeX code, but Org "does not know" what that literal code consists of. The user who enters the literal LaTeX code is the one who has the duty to add the necessary elements to that code so that it is compiled correctly by LaTeX. Let's look at this as a territorial question: Scenario A: @@LaTeX:\libebreak@@ [ipsum] ==> the problem is in Org territory Scenario B: lorem\\ @@latex:[ipsum]@@ ==> the problem is in the user's territory Best regards, Juan Manuel ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 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 6:06 ` Max Nikulin 0 siblings, 2 replies; 32+ messages in thread From: Ihor Radchenko @ 2024-01-20 18:47 UTC (permalink / raw) To: Juan Manuel Macías; +Cc: orgmode, Max Nikulin Juan Manuel Macías <maciaschain@posteo.net> writes: > Scenario B: > > lorem\\ @@latex:[ipsum]@@ ==> the problem is in the user's territory I see your point. Although I am still a bit hesitant to remove `org-latex-line-break-safe'. What would be the benefit of removing it? For now, I mostly just see that it will make the life harder for users in Scenario B. For verse blocks, AFAIU, even \\ is problematic. (Correct me if I am wrong) -- 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> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 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 6:06 ` Max Nikulin 1 sibling, 1 reply; 32+ messages in thread From: Juan Manuel Macías @ 2024-01-20 20:27 UTC (permalink / raw) To: Ihor Radchenko; +Cc: orgmode, Max Nikulin Ihor Radchenko writes: > I see your point. > Although I am still a bit hesitant to remove > `org-latex-line-break-safe'. > What would be the benefit of removing it? For now, I mostly just see > that it will make the life harder for users in Scenario B. It's a complicated situation, because we now have two solutions to the same problem... It certainly sounds a bit abrupt to remove org-latex-line-break-safe (at least for now). I see no problem in both solutions coexisting. After all, the user can always give an "\\\\" value to org-latex-line-break-safe. The other possibility is that org-latex-line-break-safe is selectively deleted, as you mentioned in a previous email. In tables and verse blocks, unless I'm missing something, I think adding [0pt] would be unnecessary, with the new solution. > For verse blocks, AFAIU, even \\ is problematic. (Correct me if I am wrong) From the tests I have done, the problem of the vertical space being altered after the verse environment only appears when the last line ends in \\[0pt]. If it ends in \\ the problem does not appear. It is not recommended that a verse environment ends in \\, but it does not seem to influence the output. In fact, that was how it was in Org in the days pre org-latex-line-break-safe and there were never any problems. Best regards, Juan Manuel ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 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 0 siblings, 2 replies; 32+ messages in thread From: Ihor Radchenko @ 2024-01-21 13:42 UTC (permalink / raw) To: Juan Manuel Macías; +Cc: orgmode, Max Nikulin [-- Attachment #1: Type: text/plain, Size: 1386 bytes --] Juan Manuel Macías <maciaschain@posteo.net> writes: >> Although I am still a bit hesitant to remove >> `org-latex-line-break-safe'. >> What would be the benefit of removing it? For now, I mostly just see >> that it will make the life harder for users in Scenario B. > > It's a complicated situation, because we now have two solutions to the > same problem... It certainly sounds a bit abrupt to remove > org-latex-line-break-safe (at least for now). I see no problem in both > solutions coexisting. After all, the user can always give an "\\\\" > value to org-latex-line-break-safe. The other possibility is that > org-latex-line-break-safe is selectively deleted, as you mentioned in a > previous email. In tables and verse blocks, unless I'm missing > something, I think adding [0pt] would be unnecessary, with the new > solution. Upon looking closer into selective removal, it turned out to be more tricky than I thought. I'm afraid that using \\[0pt] only in some places may become a bit of headache to maintain - we may accidentally break certain regexp replacements in `org-latex-verse-block'. In particular, when verse contents is not straightforward and uses \\[0pt]. Given that `org-latex-line-break-safe' also introduced the problem with verse blocks, I decided that it is better to remove it at the end. See the attached tentative patchset. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: v2-0001-ox-latex-Make-sure-that-text-is-not-misinterprete.patch --] [-- Type: text/x-patch, Size: 2518 bytes --] From d2e74cc2734eaf8d782f5acf66b11956d6ffa47e Mon Sep 17 00:00:00 2001 Message-ID: <d2e74cc2734eaf8d782f5acf66b11956d6ffa47e.1705844367.git.yantar92@posteo.net> From: Ihor Radchenko <yantar92@posteo.net> Date: Thu, 18 Jan 2024 14:01:32 +0100 Subject: [PATCH v2 1/2] ox-latex: Make sure that [text] is not misinterpreted as LaTeX argument * lisp/ox-latex.el (org-latex-plain-text): Protect plain text starting from [. It might be misinterpreted as optional command argument if previous exported fragment ends with a command accepting such. * testing/lisp/test-ox-latex.el (text-ox-latex/protect-square-brackets): Add new test. Link: https://orgmode.org/list/87o7dju9vn.fsf@posteo.net --- lisp/ox-latex.el | 9 +++++++++ testing/lisp/test-ox-latex.el | 23 +++++++++++++++++++++++ 2 files changed, 32 insertions(+) diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el index df20345f8..a64dd5a87 100644 --- a/lisp/ox-latex.el +++ b/lisp/ox-latex.el @@ -3095,6 +3095,15 @@ (defun org-latex-plain-text (text info) "\\(?:[ \t]*\\\\\\\\\\)?[ \t]*\n" (concat org-latex-line-break-safe "\n") output nil t))) + ;; Protect [foo] at the beginning of lines / beginning of the + ;; plain-text object. This prevents LaTeX from unexpectedly + ;; interpreting @@latex:\pagebreak@@ [foo] as a command with + ;; optional argument. + (setq output (replace-regexp-in-string + (rx bol (0+ space) (group "[")) + "{[}" + output + nil nil 1)) ;; Return value. output)) diff --git a/testing/lisp/test-ox-latex.el b/testing/lisp/test-ox-latex.el index 41df1b823..237ad97ec 100644 --- a/testing/lisp/test-ox-latex.el +++ b/testing/lisp/test-ox-latex.el @@ -29,6 +29,29 @@ (unless (featurep 'ox-latex) \f +(ert-deftest text-ox-latex/protect-square-brackets () + "Test [foo] being interpreted as plain text even after LaTeX commands." + (org-test-with-exported-text + 'latex + "* This is test +lorem @@latex:\\pagebreak@@ [ipsum] + +#+begin_figure +[lorem] figure +#+end_figure + +| [foo] | 2 | +| [bar] | 3 | + +- [bax] +- [aur] +" + (goto-char (point-min)) + (should (search-forward "lorem \\pagebreak {[}ipsum]")) + (should (search-forward "{[}lorem] figure")) + (should (search-forward "{[}foo]")) + (should (search-forward "\\item {[}bax]")))) + (ert-deftest test-ox-latex/verse () "Test verse blocks." (org-test-with-exported-text -- 2.43.0 [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #3: v2-0002-ox-latex-Remove-org-latex-line-break-safe.patch --] [-- Type: text/x-patch, Size: 11526 bytes --] From dd4618b31dc5070d6802e484fd58cf50f5d3606d Mon Sep 17 00:00:00 2001 Message-ID: <dd4618b31dc5070d6802e484fd58cf50f5d3606d.1705844367.git.yantar92@posteo.net> In-Reply-To: <d2e74cc2734eaf8d782f5acf66b11956d6ffa47e.1705844367.git.yantar92@posteo.net> References: <d2e74cc2734eaf8d782f5acf66b11956d6ffa47e.1705844367.git.yantar92@posteo.net> From: Ihor Radchenko <yantar92@posteo.net> Date: Sun, 21 Jan 2024 14:21:33 +0100 Subject: [PATCH v2 2/2] ox-latex: Remove org-latex-line-break-safe This reverts commit 3f60acff7717e472d06833e9cf9fff6ca3d59337 and subsequent relevant comments. * lisp/ox-latex.el (org-latex-line-break-safe): Remove constant. The \\[0pt] is actually not safe to use in some scenarios. We use a different approach to avoid plain text [...] being interpreted as LaTeX optional argument - we escape [ like {[}; that's what pandoc does. (org-latex-clock): (org-latex-line-break): (org-latex-plain-text): (org-latex-planning): (org-latex--org-table): (org-latex--math-table): (org-latex-table-row): (org-latex-verse-block): * testing/lisp/test-org-table.el (test-org-table/to-latex): * testing/lisp/test-ox-latex.el (test-ox-latex/verse): (test-ox-latex/longtable): Remove references to `org-latex-line-break-safe'. * etc/ORG-NEWS (=ox-latex=: ~org-latex-line-break-safe~ is removed): Announce removal. * lisp/org-compat.el (org-latex-line-break-safe): Make obsolete. Link: https://orgmode.org/list/878r4jg37s.fsf@posteo.net --- etc/ORG-NEWS | 10 +++++++ lisp/org-compat.el | 18 +++++++++++++ lisp/ox-latex.el | 49 ++++++++++++---------------------- testing/lisp/test-org-table.el | 6 ++--- testing/lisp/test-ox-latex.el | 16 +++++------ 5 files changed, 56 insertions(+), 43 deletions(-) diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index 847ddf614..46f1e66a7 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -13,6 +13,16 @@ Please send Org bug reports to mailto:emacs-orgmode@gnu.org. * Version 9.7 (not released yet) ** Important announcements and breaking changes +*** =ox-latex=: ~org-latex-line-break-safe~ is removed + +~org-latex-line-break-safe~ constant was previously introduced to deal +with edge cases when LaTeX interprets [...] as LaTeX command +argument. However, it caused a number of other issues and proved +itself not to be as "safe" as it supposed to be. + +We now use a Pandoc's approach to deal with the same problem, +utilizing ={[}= to escape =[...]= instances where needed. + *** ~org-agenda-search-headline-for-time~ now ignores all the timestamp in headings Previously, ~org-agenda-search-headline-for-time~ made Org agenda diff --git a/lisp/org-compat.el b/lisp/org-compat.el index 17f07db9d..27d094b07 100644 --- a/lisp/org-compat.el +++ b/lisp/org-compat.el @@ -629,6 +629,24 @@ (define-obsolete-variable-alias 'org-reveal-start-hook (define-obsolete-function-alias 'org-file-url-p 'org-url-p "9.6") (define-obsolete-variable-alias 'org-plantuml-executable-args 'org-plantuml-args "Org 9.6") + +(defconst org-latex-line-break-safe "\\\\[0pt]" + "Linebreak protecting the following [...]. + +Without \"[0pt]\" it would be interpreted as an optional argument to +the \\\\. + +This constant, for example, makes the below code not err: + +\\begin{tabular}{c|c} + [t] & s\\\\[0pt] + [I] & A\\\\[0pt] + [m] & kg +\\end{tabular}") +(make-obsolete 'org-latex-line-break-safe + "should not be used - it is not safe in all the scenarios." + "9.7") + (defun org-in-fixed-width-region-p () "Non-nil if point in a fixed-width region." (save-match-data diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el index a64dd5a87..d6e74cb45 100644 --- a/lisp/ox-latex.el +++ b/lisp/ox-latex.el @@ -298,23 +298,10 @@ (defconst org-latex-language-alist - `:script-tag' the script otf tag.") -(defconst org-latex-line-break-safe "\\\\[0pt]" - "Linebreak protecting the following [...]. -Without \"[0pt]\" it would be interpreted as an optional argument to -the \\\\. - -This constant, for example, makes the below code not err: - -\\begin{tabular}{c|c} - [t] & s\\\\[0pt] - [I] & A\\\\[0pt] - [m] & kg -\\end{tabular}") - -(defconst org-latex-table-matrix-macros `(("bordermatrix" . "\\cr") +(defconst org-latex-table-matrix-macros '(("bordermatrix" . "\\cr") ("qbordermatrix" . "\\cr") - ("kbordermatrix" . ,org-latex-line-break-safe)) + ("kbordermatrix" . "\\\\")) "Alist between matrix macros and their row ending.") (defconst org-latex-math-environments-re @@ -2124,7 +2111,7 @@ (defun org-latex-clock (clock _contents info) (concat (org-timestamp-translate (org-element-property :value clock)) (let ((time (org-element-property :duration clock))) (and time (format " (%s)" time))))) - org-latex-line-break-safe)) + "\\\\")) ;;;; Code @@ -2722,7 +2709,7 @@ ;;;; Line Break (defun org-latex-line-break (_line-break _contents _info) "Transcode a LINE-BREAK object from Org to LaTeX. CONTENTS is nil. INFO is a plist holding contextual information." - (concat org-latex-line-break-safe "\n")) + "\\\\\n") ;;;; Link @@ -3092,9 +3079,7 @@ (defun org-latex-plain-text (text info) ;; Handle break preservation if required. (when (plist-get info :preserve-breaks) (setq output (replace-regexp-in-string - "\\(?:[ \t]*\\\\\\\\\\)?[ \t]*\n" - (concat org-latex-line-break-safe "\n") - output nil t))) + "\\(?:[ \t]*\\\\\\\\\\)?[ \t]*\n" "\\\\\n" output nil t))) ;; Protect [foo] at the beginning of lines / beginning of the ;; plain-text object. This prevents LaTeX from unexpectedly ;; interpreting @@latex:\pagebreak@@ [foo] as a command with @@ -3139,7 +3124,7 @@ (defun org-latex-planning (planning _contents info) (format (plist-get info :latex-active-timestamp-format) (org-timestamp-translate scheduled))))))) " ") - org-latex-line-break-safe)) + "\\\\")) ;;;; Property Drawer @@ -3919,11 +3904,11 @@ (defun org-latex--org-table (table contents info) (format "\\begin{%s}%s{%s}\n" table-env width alignment) (and above? (org-string-nw-p caption) - (concat caption org-latex-line-break-safe "\n")) + (concat caption "\\\\\n")) contents (and (not above?) (org-string-nw-p caption) - (concat caption org-latex-line-break-safe "\n")) + (concat caption "\\\\\n")) (format "\\end{%s}" table-env) (and fontsize "}")))) (t @@ -4008,7 +3993,7 @@ (defun org-latex--math-table (table info) (lambda (cell) (substring (org-element-interpret-data cell) 0 -1)) (org-element-map row 'table-cell #'identity info) "&") - (or (cdr (assoc env org-latex-table-matrix-macros)) org-latex-line-break-safe) + (or (cdr (assoc env org-latex-table-matrix-macros)) "\\\\") "\n"))) (org-element-map table 'table-row #'identity info) ""))) (concat @@ -4083,7 +4068,7 @@ (defun org-latex-table-row (table-row contents info) (setq table-head-cache (make-hash-table :test #'eq)) (plist-put info :org-latex-table-head-cache table-head-cache)) (if-let ((head-contents (gethash (org-element-parent table-row) table-head-cache))) - (puthash (org-element-parent table-row) (concat head-contents org-latex-line-break-safe "\n" contents) + (puthash (org-element-parent table-row) (concat head-contents "\\\\\n" contents) table-head-cache) (puthash (org-element-parent table-row) contents table-head-cache)))) ;; Return LaTeX string as the transcoder. @@ -4092,7 +4077,7 @@ (defun org-latex-table-row (table-row contents info) ;; hline was specifically marked. (and booktabsp (not (org-export-get-previous-element table-row info)) "\\toprule\n") - contents org-latex-line-break-safe "\n" + contents "\\\\\n" (cond ;; Special case for long tables. Define header and footers. ((and longtablep (org-export-table-row-ends-header-p table-row info)) @@ -4100,9 +4085,9 @@ (defun org-latex-table-row (table-row contents info) (org-element-lineage table-row 'table) info)))) (format "%s \\endfirsthead -\\multicolumn{%d}{l}{%s} \\\\[0pt] +\\multicolumn{%d}{l}{%s} \\\\ %s -%s \\\\[0pt]\n +%s \\\\\n %s \\endhead %s\\multicolumn{%d}{r}{%s} \\\\ @@ -4211,15 +4196,15 @@ (defun org-latex-verse-block (verse-block contents info) (replace-regexp-in-string (if (not lit) (rx-to-string - `(seq (group ,org-latex-line-break-safe "\n") - (1+ (group line-start (0+ space) ,org-latex-line-break-safe "\n")))) - (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$")) + `(seq (group "\\\\\n") + (1+ (group line-start (0+ space) "\\\\\n")))) + "^[ \t]*\\\\$") (if (not lit) (if lin "\\\\!\n\n" "\n\n") "\\vspace*{\\baselineskip}") (replace-regexp-in-string "\\([ \t]*\\\\\\\\\\)?[ \t]*\n" - (concat org-latex-line-break-safe "\n") + "\\\\\n" (if (not lit) (concat (org-trim contents t) "\n") contents) diff --git a/testing/lisp/test-org-table.el b/testing/lisp/test-org-table.el index 92ccd2a05..6ee790894 100644 --- a/testing/lisp/test-org-table.el +++ b/testing/lisp/test-org-table.el @@ -1633,11 +1633,11 @@ (ert-deftest test-org-table/to-generic () (ert-deftest test-org-table/to-latex () "Test `orgtbl-to-latex' specifications." (should - (equal "\\begin{tabular}{l}\na\\\\[0pt]\n\\end{tabular}" + (equal "\\begin{tabular}{l}\na\\\\\n\\end{tabular}" (orgtbl-to-latex (org-table-to-lisp "| a |") nil))) ;; Test :environment parameter. (should - (equal "\\begin{tabularx}{l}\na\\\\[0pt]\n\\end{tabularx}" + (equal "\\begin{tabularx}{l}\na\\\\\n\\end{tabularx}" (orgtbl-to-latex (org-table-to-lisp "| a |") '(:environment "tabularx")))) ;; Test :booktabs parameter. @@ -1646,7 +1646,7 @@ (ert-deftest test-org-table/to-latex () "\\toprule" (orgtbl-to-latex (org-table-to-lisp "| a |") '(:booktabs t)))) ;; Handle LaTeX snippets. (should - (equal "\\begin{tabular}{l}\n\\(x\\)\\\\[0pt]\n\\end{tabular}" + (equal "\\begin{tabular}{l}\n\\(x\\)\\\\\n\\end{tabular}" (orgtbl-to-latex (org-table-to-lisp "| $x$ |") nil))) ;; Test pseudo objects and :raw parameter. (should diff --git a/testing/lisp/test-ox-latex.el b/testing/lisp/test-ox-latex.el index 237ad97ec..d0be4e5a4 100644 --- a/testing/lisp/test-ox-latex.el +++ b/testing/lisp/test-ox-latex.el @@ -71,14 +71,14 @@ (ert-deftest test-ox-latex/verse () (should (search-forward "\\begin{verse} -lorem ipsum dolor\\\\[0pt] +lorem ipsum dolor\\\\ lorem ipsum dolor -lorem ipsum dolor\\\\[0pt] +lorem ipsum dolor\\\\ lorem ipsum dolor -lorem ipsum dolor\\\\[0pt] -lorem ipsum dolor\\\\[0pt] +lorem ipsum dolor\\\\ +lorem ipsum dolor\\\\ \\end{verse}")))) (ert-deftest test-ox-latex/longtable () @@ -98,15 +98,15 @@ (ert-deftest test-ox-latex/longtable () (should (search-forward "\\begin{longtable}{lr} -First & Second\\\\[0pt] -Column & Column\\\\[0pt] +First & Second\\\\ +Column & Column\\\\ \\hline \\endfirsthead")) (goto-char (point-min)) (should (search-forward - "First & Second\\\\[0pt] -Column & Column \\\\[0pt] + "First & Second\\\\ +Column & Column \\\\ \\hline \\endhead")) -- 2.43.0 [-- Attachment #4: Type: text/plain, Size: 224 bytes --] -- 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> ^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 2024-01-21 13:42 ` Ihor Radchenko @ 2024-01-21 19:25 ` Juan Manuel Macías 2024-01-31 11:39 ` Ihor Radchenko 1 sibling, 0 replies; 32+ messages in thread From: Juan Manuel Macías @ 2024-01-21 19:25 UTC (permalink / raw) To: Ihor Radchenko; +Cc: orgmode, Max Nikulin Ihor Radchenko writes: > Upon looking closer into selective removal, it turned out to be more > tricky than I thought. I'm afraid that using \\[0pt] only in some places > may become a bit of headache to maintain - we may accidentally break > certain regexp replacements in `org-latex-verse-block'. In particular, > when verse contents is not straightforward and uses \\[0pt]. > > Given that `org-latex-line-break-safe' also introduced the problem with > verse blocks, I decided that it is better to remove it at the end. LaTeX code generated without org-latex-line-break-safe is much cleaner. The decision to make this variable obsolete seems correct to me, if there is already a better and more discreet solution. I don't know if it will cause many problems with custom settings and filters written in relation to this variable, as Maxim commented in a previous email... I hope not. I have a couple of filters written already, but I don't think it will take much work for me to readjust them. Best regards, Juan Manuel ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 2024-01-21 13:42 ` Ihor Radchenko 2024-01-21 19:25 ` Juan Manuel Macías @ 2024-01-31 11:39 ` Ihor Radchenko 1 sibling, 0 replies; 32+ messages in thread From: Ihor Radchenko @ 2024-01-31 11:39 UTC (permalink / raw) To: Juan Manuel Macías; +Cc: orgmode, Max Nikulin Ihor Radchenko <yantar92@posteo.net> writes: > Given that `org-latex-line-break-safe' also introduced the problem with > verse blocks, I decided that it is better to remove it at the end. > > See the attached tentative patchset. Applied, onto main. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=03b383df8 -- 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> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 2024-01-20 18:47 ` Ihor Radchenko 2024-01-20 20:27 ` Juan Manuel Macías @ 2024-01-21 6:06 ` Max Nikulin 1 sibling, 0 replies; 32+ messages in thread From: Max Nikulin @ 2024-01-21 6:06 UTC (permalink / raw) To: Juan Manuel Macías; +Cc: orgmode On 21/01/2024 01:47, Ihor Radchenko wrote: > Juan Manuel Macías writes: >> >> lorem\\ @@latex:[ipsum]@@ ==> the problem is in the user's territory I agree with Juan Manuel. > I see your point. > Although I am still a bit hesitant to remove > `org-latex-line-break-safe'. > What would be the benefit of removing it? For now, I mostly just see > that it will make the life harder for users in Scenario B. An option might be disabling it by default without removing the code completely. Depending on user feedback it may be removed later. Users, who need to submit LaTeX code, consider [0pt] as undesired noise. I see their point of view. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 2024-01-18 13:05 ` Ihor Radchenko 2024-01-19 17:28 ` Juan Manuel Macías @ 2024-01-20 10:09 ` Max Nikulin 2024-01-20 10:57 ` Juan Manuel Macías 2024-01-20 12:41 ` Ihor Radchenko 1 sibling, 2 replies; 32+ messages in thread From: Max Nikulin @ 2024-01-20 10:09 UTC (permalink / raw) To: emacs-orgmode On 18/01/2024 20:05, Ihor Radchenko wrote: > With the patch, I am getting the following:[...] > \begin{center} > \begin{tabular}{lr} > {[}foo] & 2\\[0pt] > {[}bar] & 3\\[0pt] > \end{tabular} > \end{center} It means that [0pt] is not necessary any more. However users will have adjust their filters once more. I have no idea if many of them will complain concerning {[} where it is not really required. (/[omitted]/). To have an additional excuse, it is better to add a note that it is inspired by pandoc strategy. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 2024-01-20 10:09 ` Max Nikulin @ 2024-01-20 10:57 ` Juan Manuel Macías 2024-01-20 12:41 ` Ihor Radchenko 1 sibling, 0 replies; 32+ messages in thread From: Juan Manuel Macías @ 2024-01-20 10:57 UTC (permalink / raw) To: Max Nikulin; +Cc: Ihor Radchenko, orgmode Max Nikulin writes: > On 18/01/2024 20:05, Ihor Radchenko wrote: >> With the patch, I am getting the following:[...] >> \begin{center} >> \begin{tabular}{lr} >> {[}foo] & 2\\[0pt] >> {[}bar] & 3\\[0pt] >> \end{tabular} >> \end{center} > > It means that [0pt] is not necessary any more. However users will have > adjust their filters once more. I have no idea if many of them will > complain concerning {[} where it is not really required. > (/[omitted]/). > > To have an additional excuse, it is better to add a note that it is > inspired by pandoc strategy. I agree with the note. Perhaps both strategies could coexist: by default, Ihor's code; and org-latex-line-break-safe with value "\\\\". And, after some time, the latter could become obsolete, unless a new ''raison d'etre'' is found for it... In any case, I would no longer see it necessary to modify org-latex-verse-block anymore. Best regards, Juan Manuel ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 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 1 sibling, 1 reply; 32+ messages in thread From: Ihor Radchenko @ 2024-01-20 12:41 UTC (permalink / raw) To: Max Nikulin; +Cc: emacs-orgmode Max Nikulin <manikulin@gmail.com> writes: > It means that [0pt] is not necessary any more. However users will have > adjust their filters once more. I have no idea if many of them will > complain concerning {[} where it is not really required. (/[omitted]/). We do not promise the exact way the exported LaTeX file looks like. User filters are too flexible - we cannot reasonably guarantee that they will keep working if they rely on the way Org mode transcodes to LaTeX in specific Org version. > To have an additional excuse, it is better to add a note that it is > inspired by pandoc strategy. I can add it to the code comment, but for different reason. We do not give "excuses" to make breaking changes - https://bzg.fr/en/the-software-maintainers-pledge/ But we do keep the flexibility to make changes where Org mode behavior is undefined. Like in this case. -- 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> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 2024-01-20 12:41 ` Ihor Radchenko @ 2024-01-21 5:56 ` Max Nikulin 0 siblings, 0 replies; 32+ messages in thread From: Max Nikulin @ 2024-01-21 5:56 UTC (permalink / raw) To: Juan Manuel Macías; +Cc: emacs-orgmode On 20/01/2024 19:41, Ihor Radchenko wrote: > Max Nikulin writes: > >> To have an additional excuse, it is better to add a note that it is >> inspired by pandoc strategy. > > I can add it to the code comment, but for different reason. We do not > give "excuses" to make breaking changes - https://bzg.fr/en/the-software-maintainers-pledge/ > But we do keep the flexibility to make changes where Org mode behavior > is undefined. Like in this case. De-facto \\[0pt] was a breaking change despite formal contracts. I do not consider it as a wrong decision though. It is the case when where was no good choice, instead just ones that may cause some troubles (including leaving everything as is). I recall some threads (besides ones started by Juan Manuel) where users considered [0pt] as an undesired consequence of some other changes. That is why I wrote "excuse". ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 2024-01-13 15:08 ` Ihor Radchenko 2024-01-13 16:05 ` Juan Manuel Macías @ 2024-01-20 10:27 ` Max Nikulin 2024-01-20 12:35 ` Ihor Radchenko 1 sibling, 1 reply; 32+ messages in thread From: Max Nikulin @ 2024-01-20 10:27 UTC (permalink / raw) To: Juan Manuel Macías; +Cc: orgmode On 13/01/2024 22:08, Ihor Radchenko wrote: > Juan Manuel Macías writes: > >> Can anyone think of a possible scenario where removing the '\\[0pt]' in >> the last line would cause a problem? I would suggest to strip leading and trailing newlines before processing of the block content. > In such scenario, we may technically violate what users ask us to do: > > #+begin_verse > I really want newline here\\ > #+end_verse I really want newline here@@latex:\\%@@ P.S. Juan Manuel, I have sent another message to this thread without your address in Cc. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 2024-01-20 10:27 ` Max Nikulin @ 2024-01-20 12:35 ` Ihor Radchenko 2024-01-21 5:44 ` Max Nikulin 0 siblings, 1 reply; 32+ messages in thread From: Ihor Radchenko @ 2024-01-20 12:35 UTC (permalink / raw) To: Max Nikulin; +Cc: Juan Manuel Macías, orgmode Max Nikulin <manikulin@gmail.com> writes: >>> Can anyone think of a possible scenario where removing the '\\[0pt]' in >>> the last line would cause a problem? > > I would suggest to strip leading and trailing newlines before processing > of the block content. May you elaborate? >> In such scenario, we may technically violate what users ask us to do: >> >> #+begin_verse >> I really want newline here\\ >> #+end_verse > > I really want newline here@@latex:\\%@@ This implies that Org mode does not follow its own markup. I disagree with such suggestion. -- 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> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 2024-01-20 12:35 ` Ihor Radchenko @ 2024-01-21 5:44 ` Max Nikulin 2024-01-31 15:09 ` Ihor Radchenko 0 siblings, 1 reply; 32+ messages in thread From: Max Nikulin @ 2024-01-21 5:44 UTC (permalink / raw) To: emacs-orgmode; +Cc: Juan Manuel Macías On 20/01/2024 19:35, Ihor Radchenko wrote: > Max Nikulin writes: > >>>> Can anyone think of a possible scenario where removing the '\\[0pt]' in >>>> the last line would cause a problem? >> >> I would suggest to strip leading and trailing newlines before processing >> of the block content. > > May you elaborate? I expect that #+BEGIN_VERSE From fairest creatures we desire increase, That thereby beauty’s rose might never die, #+END_VERSE is exported to \begin{verse} From fairest creatures we desire increase,\\ That thereby beauty’s rose might never die, \end{verse} and internally at some point it is represented as "From fairest creatures we desire increase,\nThat thereby beauty’s rose might never die," without leading and trailing newlines. >>> In such scenario, we may technically violate what users ask us to do: >>> >>> #+begin_verse >>> I really want newline here\\ >>> #+end_verse >> >> I really want newline here@@latex:\\%@@ > > This implies that Org mode does not follow its own markup. I disagree > with such suggestion. I do not see any use case for "\\" at the last line. Perhaps it might even cause an org-lint warning. From my point of view, it is preferable to require more verbose markup in special cases to make intentions explicit. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export 2024-01-21 5:44 ` Max Nikulin @ 2024-01-31 15:09 ` Ihor Radchenko 0 siblings, 0 replies; 32+ messages in thread From: Ihor Radchenko @ 2024-01-31 15:09 UTC (permalink / raw) To: Max Nikulin; +Cc: emacs-orgmode, Juan Manuel Macías Max Nikulin <manikulin@gmail.com> writes: >>> I would suggest to strip leading and trailing newlines before processing >>> of the block content. >> >> May you elaborate? > > I expect that > > #+BEGIN_VERSE > > > From fairest creatures we desire increase, > That thereby beauty’s rose might never die, > > > > #+END_VERSE > > is exported to > > \begin{verse} > From fairest creatures we desire increase,\\ > That thereby beauty’s rose might never die, > \end{verse} > > and internally at some point it is represented as > "From fairest creatures we desire increase,\nThat thereby beauty’s rose > might never die," > without leading and trailing newlines. This has nothing to do with what happens when exporting verse blocks. If you try a simple example like #+options: toc:nil * Heading First. Foo #+BEGIN_VERSE From fairest creatures we desire increase, That thereby beauty’s rose might never die, #+END_VERSE Bar Foo #+BEGIN_VERSE From fairest creatures we desire increase, That thereby beauty’s rose might never die, #+END_VERSE Bar you will see that lading and trailing spaces are insignificant: \section{Heading} \label{sec:orgc54e19b} First. Foo \begin{verse} \hspace*{1\fontdimen2\font}From fairest creatures we desire increase,\\ That thereby beauty’s rose might never die,\\ \end{verse} Bar Foo \begin{verse} \hspace*{1\fontdimen2\font}From fairest creatures we desire increase,\\ That thereby beauty’s rose might never die,\\ \end{verse} Bar -- 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> ^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2024-01-31 15:07 UTC | newest] Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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).