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 wh
Juan Manuel Macías writes:
> Ihor Radchenko writes:
>
>> I see no issue with defcustom in general, but can you explain what
>> practical problems it is going to solve? I am not talking about
>> aesthetics of the exported LaTeX.
>
> In my opinion it is not so much a question of aesthetics as of (l
Ihor Radchenko writes:
> I haven't seen any publication rule that prevents using valid LaTeX
> commands like this. Do you have concrete examples? If not, one could
> argue that any auto-generated output could break some imaginary rule.
No, I don't have any concrete example. But it is one thing to
Juan Manuel Macías writes:
> So, in the current situation, we can ask ourselves: is
> \empty everywhere safe? Everything points to yes. Can we be 100% sure?
> ...?
I think I've found a case where \empty 'everywhere' can produce unexpected
results. I don't know if I'm missing something, because I'
On 17/10/2022 22:01, Juan Manuel Macías wrote:
\documentclass{article}
\usepackage{tabularray}
LaTeX I have installed is too old for this package. It is marked as
"Experimental LaTeX3", so I am unsure, maybe you have found a bug in
this package.
https://ctan.org/pkg/tabularray
You believe
Max Nikulin writes:
> On 17/10/2022 22:01, Juan Manuel Macías wrote:
>> \documentclass{article}
>> \usepackage{tabularray}
>
> LaTeX I have installed is too old for this package. It is marked as
> "Experimental LaTeX3", so I am unsure, maybe you have found a bug in
> this package.
> https://ctan.o
Max Nikulin writes:
> Selectively adding some workaround require complete reimplementation of
> exporters. I have some curiosity concerning pandoc approach, but I am
> unsure if I will reserve some time to read its code.
Maybe or maybe not. We have org-export-get-next-element and a number of
e
Juan Manuel Macías writes:
> Assuming that there is currently no alternative to the non-selective
> solution, and that, as you say, the presence of brackets may be more
> common than I initially expected, if I had to choose between \empty and
> [0pt], I would say that [0pt] is the safest, as it i
Ihor Radchenko writes:
>> Assuming that there is currently no alternative to the non-selective
>> solution, and that, as you say, the presence of brackets may be more
>> common than I initially expected, if I had to choose between \empty and
>> [0pt], I would say that [0pt] is the safest, as it is
Juan Manuel Macías writes:
>> It is easy to change \\\empty constant to \\[0pt] if necessary. I have
>> no objection either way. Though I do not feel like we are in rush. I'd
>> like to hear from ox-latex maintainer.
>
> Today I have tried with the latest version of tabularray (2022C, the one
> I
On 19/10/2022 10:57, Ihor Radchenko wrote:
Juan Manuel Macías writes:
Today I have tried with the latest version of tabularray (2022C, the one
I tried yesterday was 2022A, included in TeX Live 2022), and the bad
results persist. Also, it now returns a compile error when an \empty
precedes a \hl
Max Nikulin writes:
> Another recipe should be used:
>
> | / | < | > |
> | | a | b @@latex:\rule[-1em]{0pt}{1em}@@ |
> | | c | d |
>
> I believe that a more convenient way to override [0pt] to some other
> length for particular ro
Juan Manuel Macías writes:
>> For a while I have the following question. Is \\{} have the same
>> effect on tabularray parser as \\\empty?
>
> Throw an error before \hline.
To expand on my answer: \\{} and \\\empty, before \hline, throw the same
error:
--
ERROR: Mispl
For a while I have the following question. Is \\{} have the same
effect on tabularray parser as \\\empty?
Throw an error before \hline.
It is possible to use
\begin{tblr}[expand=\empty]{rl}
but I would prefer to reserve such feature for a more nobble purpose.
I've had a
first look at ta
On 18/10/2022 11:39, Ihor Radchenko wrote:
Max Nikulin writes:
Selectively adding some workaround require complete reimplementation of
exporters. I have some curiosity concerning pandoc approach, but I am
unsure if I will reserve some time to read its code.
Maybe or maybe not. We have org-exp
Max Nikulin writes:
>>> Selectively adding some workaround require complete reimplementation of
>>> exporters. I have some curiosity concerning pandoc approach, but I am
>>> unsure if I will reserve some time to read its code.
>>
>> Maybe or maybe not. We have org-export-get-next-element and a n
Max Nikulin writes:
> I have started a discussion requesting for a \\-like command without
> optional arguments. Maybe somebody will suggest a better workaround
> instead.
> https://github.com/lvjr/tabularray/discussions/321
I've had a look at the thread. What do you think of that
\NewTableComman
Max Nikulin writes:
> A workaround for tabularray:
>
> \NewTableCommand\empty{}
>
> I am unsure if we should use it.
Ah, I had just commented on this in the email I just sent...
>> By the way, now I remember that the package verse adds a series of
>> extra
>> arguments to \\ (p. 6 in the doc
An argument in favor of \\[0pt] escaping. Unlike \empty, [0pt] is rather
artificial, so such pattern may be removed (I hope in a safe way) by an
export filter if it is not followed by a bracket or a star.
On 20/10/2022 12:07, Ihor Radchenko wrote:
When transcoding children (e.g. table rows), t
Juan Manuel Macías writes:
> I've had a look at the thread. What do you think of that
> \NewTableCommand\empty{} workaround mentioned at
> https://github.com/lvjr/tabularray/discussions/321#discussioncomment-3920957?
>
> Since the \empty option only has problems in tabularray, maybe we could
> ke
Max Nikulin writes:
> On 20/10/2022 12:07, Ihor Radchenko wrote:
>> When transcoding children (e.g. table rows), the sibling rows can always
>> be accessed using org-export-get-previous-element and
>> org-export-get-next-element.
>
> Decision if escaping is necessary should be based on export res
On 21/10/2022 10:41, Ihor Radchenko wrote:
Max Nikulin writes:
On 20/10/2022 12:07, Ihor Radchenko wrote:
When transcoding children (e.g. table rows), the sibling rows can always
be accessed using org-export-get-previous-element and
org-export-get-next-element.
Decision if escaping is necess
On 21/10/2022 10:34, Ihor Radchenko wrote:
Juan Manuel Macías writes:
I see the tabularray issue simply as an example that \empty is not as
reliable as we thought. There might be other LaTeX packages throwing
errors on \\\empty.
My impression is that tabularray has an ambitious goal to replace
Max Nikulin writes:
> My impression is that tabularray has an ambitious goal to replace all
> current table packages. I have no idea if other packages will adopt
> similar approach with regexp-based parsing instead of usual expanding
> of TeX commands.
Yes, that's the impression I have too. Tabul
Max Nikulin writes:
> Concerning element vs. exported text, consider a derived backend that
> ignores italics markers if a paragraph has some attribute. Usually
> Paragraph \\
> \emph{[something]}
> does not cause any problem, however if italics is ignored it is an error
> Para
Ihor Radchenko writes:
> Or, to be completely safe, we can introduce a defcustom that will
> control such clean-up (clean up by default).
>
> I propose the following:
> 1. Merge my patch with \\[0pt] safe page breaks
> 2. Modify org-latex-template to replace unnecessary occurrences of
>"\\[0pt
On 22/10/2022 12:15, Ihor Radchenko wrote:
as long as the next line does not match
"^[ \t]*\\["
Verse package defines \\! and \\>.
The only precaution that search pattern should ignore \\\[0pt]\] that is
a display equation "0pt]"
I propose the following:
1. Merge my patch with \\[0pt] safe
Ihor Radchenko writes:
> Then [0pt] should it be. At least for now, before we have a cleaner
> solution.
>
> See the attached patch.
Applied onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=b93a61af9c93d21c56cf883630e52f36076e40bd
I will look into filtering out unneces
Max Nikulin writes:
> On 22/10/2022 12:15, Ihor Radchenko wrote:
>> as long as the next line does not match
>> "^[ \t]*\\["
>
> Verse package defines \\! and \\>.
>
> The only precaution that search pattern should ignore \\\[0pt]\] that is
> a display equation "0pt]"
Can you please elaborate?
On 01/11/2022 08:51, Ihor Radchenko wrote:
Max Nikulin writes:
On 22/10/2022 12:15, Ihor Radchenko wrote:
as long as the next line does not match
"^[ \t]*\\["
Verse package defines \\! and \\>.
The only precaution that search pattern should ignore \\\[0pt]\] that is
a display equation "0pt]
Max Nikulin writes:
> LaTeX verse package require "\\!" as stanza separator to get proper line
> count,
> so square bracket on the next line is not the only character that may change
> meaning of "\\". So "[*!>" (depending on context) should be handled.
Only when the separation between stanzas i
Max Nikulin writes:
> Another corner case when "\\[0pt]\n" should not be blindly replaced to
> "\\\n" (I do not escape "\"). Imagine that you are going to describe
> this optimizing filter
>
> >8
> Optimizing filter will replace
> #+begin_example
> First\\[0pt]
> Second
> #+end_exampl
Ihor Radchenko writes:
> Should we, instead of using exact "\\[0pt]" string for line breaks,
> define a new LaTeX command and then clean it up? This will distinguish
> between \\[0pt] added by users explicitly and the ones generated
> automatically by Org.
I guess it will not work for that fancy
On 02/11/2022 13:46, Ihor Radchenko wrote:
Ihor Radchenko writes:
Should we, instead of using exact "\\[0pt]" string for line breaks,
define a new LaTeX command and then clean it up? This will distinguish
between \\[0pt] added by users explicitly and the ones generated
automatically by Org.
I
Max Nikulin writes:
> On 02/11/2022 13:46, Ihor Radchenko wrote:
>> Ihor Radchenko writes:
>>
>>> Should we, instead of using exact "\\[0pt]" string for line breaks,
>>> define a new LaTeX command and then clean it up? This will distinguish
>>> between \\[0pt] added by users explicitly and the o
Ihor Radchenko writes:
> These arguments mean that auto-cleaning \\[0pt] is not always safe and
> may be a subject of surrounding LaTeX context. Moreover, there is no
> clear alternative to \\[0pt] that is guaranteed to work.
> Thus, the whole idea with cleaning up the generated LaTeX cannot be
>
Ihor Radchenko writes:
These arguments mean that auto-cleaning \\[0pt] is not always safe and
may be a subject of surrounding LaTeX context.
I still believe that
something\\[0pt]%__ORG_EXPORT__
is quite safe to remove (depending on the following character) and
unlikely harmful if remain
Max Nikulin writes:
> I have not managed to convince even the tabularray developer. And I
> have not tried to find a way to reach more LaTeX developers.
I think that people from the LaTeX team and the authors of the most
popular packages are often very active on tex.stackexchange.com
And the rep
Max Nikulin writes:
>> Ihor Radchenko writes:
>>
>>> These arguments mean that auto-cleaning \\[0pt] is not always safe and
>>> may be a subject of surrounding LaTeX context.
>
> I still believe that
>
> something\\[0pt]%__ORG_EXPORT__
>
> is quite safe to remove (depending on the following
On 04/11/2022 11:23, Ihor Radchenko wrote:
Max Nikulin writes:
Ihor Radchenko writes:
These arguments mean that auto-cleaning \\[0pt] is not always safe and
may be a subject of surrounding LaTeX context.
I still believe that
something\\[0pt]%__ORG_EXPORT__
is quite safe to remove (de
Max Nikulin writes:
>>> I still believe that
>>>
>>> something\\[0pt]%__ORG_EXPORT__
>>>
>>> is quite safe to remove (depending on the following character) and
>>> unlikely harmful if remained for some reason.
>>
>> What about the side effect you mentioned in a previous email?
>>
>>>
On 29/10/2022 09:36, Ihor Radchenko wrote:
Ihor Radchenko writes:
Then [0pt] should it be. At least for now, before we have a cleaner
solution.
See the attached patch.
Applied onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=b93a61af9c93d21c56cf883630e52f36076e40bd
Max Nikulin writes:
> In my opinion Org has to apply a general solution merely because a table
> may be result of evaluation of an org-babel code block. I may be wrong,
> but I suspect that some users do not care what is the intermediate
> format when they need a PDF file.
>
>> And finally, I t
Juan Manuel Macías writes:
> The solution of adding \relax or \empty is a good one. The problem is
> when it is applied massively and indiscriminately, bearing in mind that
> it is to prevent a problem that is, frankly, very rare. \empty is
> unlikely to have any side effects, but still, I don't
44 matches
Mail list logo
