Re: Issues with nested begin..end blocks in inline math environments
Nicolas Goaziou writes: > I don't think this patch is a good idea, as it mixes elements from > different types: LaTeX fragment (inline), and LaTeX environment (block). > For example, the regexp you modify is used as a paragraph separator, > which doesn't make sense for inline LaTeX. No worries. Thanks for taking a look at this anyway. Matt
Re: Issues with nested begin..end blocks in inline math environments
Hello,
Matt Huszagh writes:
> I'm submitting this as a patch. I've used it on hundreds of latex
> fragments over the past week or so and haven't experienced any issues
> (which is expected since the change is small).
>
> From a699b699ed4132839c39f1152868bb13364422c7 Mon Sep 17 00:00:00 2001
> From: Matt Huszagh
> Date: Sat, 14 Dec 2019 19:54:41 -0800
> Subject: [PATCH] org-element.el: allow environment blocks in math delimiters
>
> * lisp/org-element.el (org-element--latex-begin-environment): Add a
> non-capturing block for `\(' or `$' so that previously recognized
> latex environments can also appear within an inline math environment.
>
> * lisp/org-element.el (org-element--latex-end-environment): Match the
> begin environment noncapturing block with `$' or `\)'.
I don't think this patch is a good idea, as it mixes elements from
different types: LaTeX fragment (inline), and LaTeX environment (block).
For example, the regexp you modify is used as a paragraph separator,
which doesn't make sense for inline LaTeX.
As a reminder, Org does not claim to support raw LaTeX syntax besides
very simple constructs. If you want to insert elaborate LaTeX code, you
can always use:
#+begin_export latex
...
#+end_export
Regards,
--
Nicolas Goaziou
Re: Issues with nested begin..end blocks in inline math environments
I'm submitting this as a patch. I've used it on hundreds of latex
fragments over the past week or so and haven't experienced any issues
(which is expected since the change is small).
>From a699b699ed4132839c39f1152868bb13364422c7 Mon Sep 17 00:00:00 2001
From: Matt Huszagh
Date: Sat, 14 Dec 2019 19:54:41 -0800
Subject: [PATCH] org-element.el: allow environment blocks in math delimiters
* lisp/org-element.el (org-element--latex-begin-environment): Add a
non-capturing block for `\(' or `$' so that previously recognized
latex environments can also appear within an inline math environment.
* lisp/org-element.el (org-element--latex-end-environment): Match the
begin environment noncapturing block with `$' or `\)'.
---
lisp/org-element.el | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lisp/org-element.el b/lisp/org-element.el
index 110ff5624..6d7ec32c6 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -,14 +,14 @@ containing `:key', `:value', `:begin', `:end', `:post-blank' and
Latex Environment
(defconst org-element--latex-begin-environment
- "^[ \t]*begin{\\([A-Za-z0-9*]+\\)}"
+ "^[ \t]*\\(?:(\\|\\$\\)?begin{\\([A-Za-z0-9*]+\\)}"
"Regexp matching the beginning of a LaTeX environment.
The environment is captured by the first group.
See also `org-element--latex-end-environment'.")
(defconst org-element--latex-end-environment
- "end{%s}[ \t]*$"
+ "end{%s}[ \t]*\\(?:)\\|\\$\\)?$"
"Format string matching the ending of a LaTeX environment.
See also `org-element--latex-begin-environment'.")
--
2.24.0
Re: Issues with nested begin..end blocks in inline math environments
"Fraga, Eric" writes:
> The identification of LaTeX fragments is somewhat fragile (in my
> experience). I would suggest you enclose complex LaTeX code fragments
> within an #+begin_export latex ... #+end_export environment.
>
> Assuming your export target is LaTeX and/or PDF.
Changing the beginning and end regexes to the following seems to work
well (I've just added a non-capturing group for \(\) or $$ so that
begin-end blocks can be nested inside inline math environments).
(setq org-element--latex-begin-environment "^[
\t]*\\(?:(\\|\\$\\)?begin{\\([A-Za-z0-9*]+\\)}")
(setq org-element--latex-end-environment "end{%s}[
\t]*\\(?:)\\|\\$\\)?$")
I'm going to test this a bit before submitting it as a patch to make
sure it doesn't cause any issues. If you have any tricky fragments you
want to test it on please let me how it works!
Re: Issues with nested begin..end blocks in inline math environments
"Fraga, Eric" writes: > The identification of LaTeX fragments is somewhat fragile (in my > experience). I would suggest you enclose complex LaTeX code fragments > within an #+begin_export latex ... #+end_export environment. > > Assuming your export target is LaTeX and/or PDF. Thanks for the suggestion. Unfortunately these are mostly just used as latex previews in the org buffer. I'm going to try to improve support for this when I get the time since I use this capability extensively. If you have any thoughts/suggestions on best ways to improve this I'd be happy to hear them.
Re: Issues with nested begin..end blocks in inline math environments
On Friday, 6 Dec 2019 at 11:42, Matt Huszagh wrote: > I'm experiencing incorrect and seemingly inconsistent behavior when nesting > `\begin` `\end` environments inside `\(\)` or `$$`. For example, the > following is valid latex code: The identification of LaTeX fragments is somewhat fragile (in my experience). I would suggest you enclose complex LaTeX code fragments within an #+begin_export latex ... #+end_export environment. Assuming your export target is LaTeX and/or PDF. -- Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c
Issues with nested begin..end blocks in inline math environments
I'm experiencing incorrect and seemingly inconsistent behavior when nesting
`\begin` `\end` environments inside `\(\)` or `$$`. For example, the
following is valid latex code:
```
\(\begin{aligned}
b_n &= \frac{1}{\pi} \int_{0}^{\pi} x \sin{\left(nx\right)}dx \\
b_0 &= 0 \\
\int_{0}^{\pi} udv &= \left[uv\right]_{0}^{\pi}
- \int_{0}^{\pi} vdu \\
dv &= \sin{\left(nx\right)}dx \\
v(x) &= \int \sin{\left(nx\right)}dx \\
&= -\frac{\cos{\left(nx\right)}}{n} \\
\left[uv\right]_{0}^{\pi} &=
-\left[\frac{x\cos{\left(nx\right)}}{n}\right]_{0}^{\pi} \\
&= \left\{\begin{alignedat}{2}
\frac{\pi}{n}&, && \quad \text{$n$ odd} \\
-\frac{\pi}{n}&, && \quad \text{$n$ positive even} \\
\end{alignedat}\right. \\
\int_{0}^{\pi} vdu &=
\int_{0}^{\pi} -\frac{\cos{\left(nx\right)}}{n} dx \\
&= -\frac{1}{n^2} \left.\sin{\left(nx\right)}\right|_{0}^{\pi} \\
&= 0 \\
b_{n\in \mathbb{Z}^+} &= \left\{\begin{alignedat}{2}
\frac{1}{n}&, && \quad \text{$n$ odd} \\
-\frac{1}{n}&, && \quad \text{$n$ positive even} \\
\end{alignedat}\right. \\
\end{aligned}\)
```
But this confuses org which is generating images for the `\begin{aligned}`
at the top and the `\text` macros, but nothing else. Iterations on this
sometimes work fine, however. For example,
```
\(\begin{aligned}
b_{n\in \mathbb{Z}^+} &= \left\{\begin{alignedat}{2}
\frac{1}{n}&, && \quad \text{$n$ odd} \\
-\frac{1}{n}&, && \quad \text{$n$ positive even} \\
\end{alignedat}\right. \\
\end{aligned}\)
```
typesets correctly. Has anyone else had trouble with the latex fragment
regex's?
