On 20/01/2024 23:04, Ihor Radchenko wrote:
On 18/02/2023 17:18, Ihor Radchenko wrote:
Inhttps://orgmode.org/worg/org-faq.html#org60202b9, the answer uses
obsolete function `org-add-link-type'. We should change it to
`org-link-set-parameters'.
Fixed.
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
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 -
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
While trying out more about basic citations, with quotes to mark strings so I
can see where whitespace matters, I found that when exporting to LaTeX some
regular quote marks (") turn into fancy ones (“”) but others don't.
Let's say we have Basic.bib (now in testing/examples/, adjust path as
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
Ihor Radchenko writes:
> Max Nikulin writes:
>
>> https://list.orgmode.org/87bl21vazj@posteo.net
>>
>> Likely should be modified a bit to support derived backends.
>
> I think we do not do this in any of the examples for :export link
> property in WORG. I am actually not sure how to update
Matt writes:
> How far does backwards compatibility extend with regard to Org itself?
> For the next version, for all time, or something else?
Usually, until next major release (we should have major releases more
frequently in future).
However, we often keep compat code in place even much
Juan Manuel Macías 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
gerard.vermeu...@posteo.net writes:
>> How about the attached patch?
>
> I have attached a modification of your patch. I think it is clearer
> with
> the risk of being too verbose, but the docstring width is < 80.
Thanks!
Applied, onto main.
I'm going to defer these changes for now. It seems like it would be easier to
handle renaming one function/variable at a time. Renaming requires creating an
alias mapping between the old name and the new one. Any subsequent refactoring
would require updating the mapping. It seems better to
On Tue, 16 Jan 2024 14:10:00 +0100 Ihor Radchenko wrote ---
> I do not mind changing the names, except that we must not break
> backwards compatibility. In particular, the non-private function
> and variable names that were present in the latest Org stable
> release must be either
Max Nikulin writes:
> On 18/02/2023 17:18, Ihor Radchenko wrote:
>> In https://orgmode.org/worg/org-faq.html#org60202b9, the answer uses
>> obsolete function `org-add-link-type'. We should change it to
>> `org-link-set-parameters'.
>
> Confirmed.
Fixed.
Ihor Radchenko writes:
> Juan Manuel Macías 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
Ihor Radchenko writes:
>> Feel free to propose a patch for this and the suggested switch, we can
>> apply it after Org 9.4.
>
> I will add it to my todo list. This should be lower priority than org-fold.el
See the attached patch.
>From 175937da259fe0b29057d69055bf3469aa1a8679 Mon Sep 17
Ihor Radchenko writes:
> Leo Butler writes:
>
>> The following Org document shows a bug in the beamer exporter.
>
> Confirmed on main.
I investigated further.
> There are two bugs reported here:
> 1. ox-latex export bug for src blocks containing direct LaTeX when
>
Ihor Radchenko writes:
>> Expected: The lowest priority is selected: [#]
>>
>> Actual: Only the first byte of the lowest priority is selected: [#]
>
> Try M-x describe-char on any of these emojis.
> Org mode relies on `string-to-char' to extract the priority char and
> (insert (string-to-char
On 20.01.2024 13:18, Ihor Radchenko wrote:
gerard.vermeu...@posteo.net writes:
I suspect that you may have some misunderstanding about how
`org-babel-detangle' works. Its docstring says:
Propagate changes in source file back original to Org file.
So, it is expected to run from the
Juan Manuel Macías 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.
Ihor Radchenko writes:
> Juan Manuel Macías 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
Max Nikulin 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
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?
>> In such scenario, we may
Juan Manuel Macías 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
gerard.vermeu...@posteo.net writes:
>> I suspect that you may have some misunderstanding about how
>> `org-babel-detangle' works. Its docstring says:
>>
>>Propagate changes in source file back original to Org file.
>>
>> So, it is expected to run from the tangled file; not from the Org
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
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
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
27 matches
Mail list logo
