The following Org markup does not render properly in HTML export:
- foo $a<b$ bar foo $b>a$ bar
In Emacs, I see no signs of problems, such as broken math
highlighting. Further, when I export to LaTeX, the inequalities
render properly. Does one have to use \lt and \gt instead of < and
> all the time? If so, why allow < and > characters in math
blocks? I ask because, when I reorganize my Org document, it
breaks math "at random" when I use < and > and Emacs does not tell
me about it.
R+
--
Logic is a science of the necessary laws of thought, without which
no employment of the understanding and the reason takes place. --
Immanuel Kant, 1785 Rudolf Adamkovič <salutis@me.com>
Studenohorská 25 84103 Bratislava Slovakia [he/him]
On 03/10/2021 18:04, Rudolf Adamkovič wrote: > The following Org markup does not render properly in HTML export: > > - foo $a<b$ bar foo $b>a$ bar > In Emacs, I see no signs of problems, such as broken math highlighting. > Further, when I export to LaTeX, the inequalities render properly. Does > one have to use \lt and \gt instead of < and >> all the time? If so, why allow < and > characters in math > blocks? I ask because, when I reorganize my Org document, it breaks math > "at random" when I use < and > and Emacs does not tell me about it. I had another reason to look into the manual today, so I noticed: https://orgmode.org/manual/Math-formatting-in-HTML-export.html > (131) > > Please note that exported formulas are part of an HTML document, and > that signs such as ‘<’, ‘>’, or ‘&’ have special meanings. See MathJax > TeX and LaTeX support. The link is broken however. http://docs.mathjax.org/en/latest/input/tex/html.html#html-special-characters > Usually, it is sufficient simply to put spaces around these symbols to > cause the browser to avoid them, so > > ... when $x < y$ we have ... Though I am a bit surprised that Org did not replace characters to < and > during export. Perhaps, it is possible to define a filter.
[-- Attachment #1: Type: text/plain, Size: 441 bytes --] Hi Rudolf and Max, >> Usually, it is sufficient simply to put spaces around these symbols to >> cause the browser to avoid them, so >> … when x < y we have … > > Though I am a bit surprised that Org did not replace characters to < and > > during export. Perhaps, it is possible to define a filter. You’re going to be much better off if you just use LaTeX math delimiters, i.e. `\( ... \)'. All the best, Timothy
Max Nikulin <manikulin@gmail.com> writes:
> Though I am a bit surprised that Org did not replace characters
> to < and > during export. Perhaps, it is possible to
> define a filter.
That makes sense, and thank you for the explanation. Ignoring the
dead link in the Org manual, I wonder how this bug can even exist
in Org after 15+ years of development. Some people, including the
author of TeX himself, write TeX without unnecessary whitespace.
Strange! Either way, rearranging bullet points should never break
math without any visual sign inside of Emacs. Thus, this
represents a bug in Org.
R+
--
I love deadlines. I love the whooshing noise they make as they go
by. -- Douglas Adams, The Salmon of Doubt Rudolf Adamkovič
<salutis@me.com> Studenohorská 25 84103 Bratislava Slovakia
[he/him]
[-- Attachment #1: Type: text/plain, Size: 862 bytes --] On 03/10/2021 19:19, Max Nikulin wrote: > > https://orgmode.org/manual/Math-formatting-in-HTML-export.html > >> (131) >> >> Please note that exported formulas are part of an HTML document, and >> that signs such as ‘<’, ‘>’, or ‘&’ have special meanings. See MathJax >> TeX and LaTeX support. > > The link is broken however. > > http://docs.mathjax.org/en/latest/input/tex/html.html#html-special-characters > >> Usually, it is sufficient simply to put spaces around these symbols to >> cause the browser to avoid them, so >> >> ... when $x < y$ we have ... > > Though I am a bit surprised that Org did not replace characters to < > and > during export. Perhaps, it is possible to define a filter. Let's fix at least the link. Old one gives 404 error. P.S. Curiously outside of math snippets "<>" are properly exported to "<>" [-- Attachment #2: 0001-org-manual.org-Update-links-to-MathJax-docs.patch --] [-- Type: text/x-patch, Size: 1628 bytes --] From be815b1476b5119db6c83363e1c7b2034b692ca6 Mon Sep 17 00:00:00 2001 From: Max Nikulin <manikulin@gmail.com> Date: Sun, 3 Oct 2021 23:12:11 +0700 Subject: [PATCH] org-manual.org: Update links to MathJax docs * doc/org-manual.org (Footnotes): Fix links to particular sections in MathJax manual. Scheme is not changed to https: since the site prefers http: curl -I https://docs.mathjax.org/ HTTP/2 302 date: Sun, 03 Oct 2021 16:04:15 GMT location: http://docs.mathjax.org/en/latest/ --- doc/org-manual.org | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/org-manual.org b/doc/org-manual.org index b25da7889..52306caa6 100644 --- a/doc/org-manual.org +++ b/doc/org-manual.org @@ -22121,9 +22121,9 @@ semantic relevance. [fn:130] Please note that exported formulas are part of an HTML document, and that signs such as =<=, =>=, or =&= have special -meanings. See [[http://docs.mathjax.org/en/latest/tex.html#tex-and-latex-in-html-documents][MathJax TeX and LaTeX support]]. +meanings. See [[http://docs.mathjax.org/en/latest/input/tex/html.html#tex-and-latex-in-html-documents][MathJax TeX and LaTeX in HTML documents]]. -[fn:131] See [[http://docs.mathjax.org/en/latest/tex.html#tex-extensions][TeX and LaTeX extensions]] in the [[http://docs.mathjax.org][MathJax manual]] to learn +[fn:131] See [[http://docs.mathjax.org/en/latest/input/tex/extensions.html#tex-and-latex-extensions][TeX and LaTeX extensions]] in the [[http://docs.mathjax.org][MathJax manual]] to learn about extensions. [fn:132] If the classes on TODO keywords and tags lead to conflicts, -- 2.25.1
Timothy <tecosaur@gmail.com> writes:
> You’re going to be much better off if you just use LaTeX math
> delimiters, i.e. `\( ... \)'.
Interesting. It works, but I do not understand why! Do we consider
inequalities in $$ breaking HTML export expected behavior? Or, do
we consider it a bug? I suppose there exists no formal
specification, executable or not, to answer the question? I ask
because if $…$ breaks basic mathematics, I should either return
back to LaTeX for any serious notes or replace every $…$ with
\(…\) in all my Org files to avoid accidental breakage of
mathematics in the future. Thank you!
R+
--
Programming reliably --- must be an activity of an undeniably
mathematical nature [...] You see, mathematics is about thinking,
and doing mathematics is always trying to think as well as
possible. -- Edsger W. Dijkstra (1981) Rudolf Adamkovič
<salutis@me.com> Studenohorská 25 84103 Bratislava Slovakia
[he/him]
[-- Attachment #1: Type: text/plain, Size: 1295 bytes --] Hi Rudolf, >> You’re going to be much better off if you just use LaTeX math delimiters, i.e. >> `...’. > > Interesting. It works, but I do not understand why! Do we consider inequalities > in $$ breaking HTML export expected behavior? Or, do we consider it a bug? I > suppose there exists no formal specification, executable or not, to answer the > question? Just considering the general situation, $ is hard for Org because it needs to do “double duty” as both a currency symbol in text, and math delimiters. This means that it can’t be consistent with how LaTeX works. However, `\( ... \)' doesn’t and so Org can be much more consistent with LaTeX here. Besides which `$ ... $' is a TeX-ism and `\( ... \)' is the /proper/ way of doing inline maths in LaTeX, so really you should be reaching for those anyway. > I ask because if … breaks basic mathematics, I should either return > back to LaTeX for any serious notes or replace every … with … in all my > Org files to avoid accidental breakage of mathematics in the future. Thank you! I’d just use `\( ... \)' in future, and that way you’ll be fine in LaTeX and Org 🙂. You might be able to use `org-element-map' to robustly convert from $ … $= to `\( ... \)'. All the best, Timothy
On 05/10/2021 14:55, Rudolf Adamkovič wrote: > Timothy writes: > >> You’re going to be much better off if you just use LaTeX math >> delimiters, i.e. `\( ... \)'. > > Interesting. It works, but I do not understand why! Did you inspect HTML file? Playing with export, I do not see real difference. Result is "\(1<2\)" even for $1<2$. info "(org) LaTeX fragments" https://orgmode.org/manual/LaTeX-fragments.html highlight some issues with $: > To avoid conflicts with currency specifications, single ‘$’ characters > are only recognized as math delimiters if the enclosed text contains at > most two line breaks, is directly attached to the ‘$’ characters with no > whitespace in between, and if the closing ‘$’ is followed by whitespace, > punctuation or a dash. For the other delimiters, there is no such > restriction, so when in doubt, use ‘\(...\)’ as inline math delimiters. > Do we consider > inequalities in $$ breaking HTML export expected behavior? Or, do we > consider it a bug? I suppose there exists no formal specification, > executable or not, to answer the question? Tom Gillespie mentioned in another thread yesterday: https://orgmode.org/worg/dev/org-syntax.html#Entities_and_LaTeX_Fragments > It would introduce incompatibilities with previous Org versions, but > support for $...$ (and for symmetry, $$...$$) constructs ought to be > removed. > > They are slow to parse, fragile, redundant and imply false > positives. — ngz
Slightly off-topic but, just in case anybody is interested, here is some code I use to allow me to easily get \(...\) by typing $: #+begin_src emacs-lisp ;; from Nicolas Richard <theonewiththeevillook@yahoo.fr> ;; Date: Fri, 8 Mar 2013 16:23:02 +0100 ;; Message-ID: <87vc913oh5.fsf@yahoo.fr> (defun yf/org-electric-dollar nil "When called once, insert \\(\\) and leave point in between. When called twice, replace the previously inserted \\(\\) by one $." (interactive) (if (and (looking-at "\\\\)") (looking-back "\\\\(")) (progn (delete-char 2) (delete-char -2) (insert "$")) (insert "\\(\\)") (backward-char 2))) (define-key org-mode-map (kbd "$") 'yf/org-electric-dollar) #+end_src Typing two $ in a row inserts a single $. -- : Eric S Fraga via Emacs 28.0.60, Org release_9.5-30-g9e71df : Latest paper written in org: https://arxiv.org/abs/2106.05096
Max Nikulin <manikulin@gmail.com> writes:
> On 05/10/2021 14:55, Rudolf Adamkovič wrote:
>> Timothy writes:
>>> You’re going to be much better off if you just use LaTeX math
>>> delimiters, i.e. `\( ... \)'.
>>
>> Interesting. It works, but I do not understand why!
>
> Did you inspect HTML file? Playing with export, I do not see
> real difference. Result is "\(1<2\)" even for $1<2$.
Oops! I spoke too soon. I re-tried \( and \) with "1" and "2"
instead of "a" and "b", but that does not break HTML rendering in
Firefox. When I use "a" and "b" instead, like I did in my original
post, it does break rendering with both $$ and \( and \).
- \(a>b\) \(b<a\) $a>b$ $b<a$ I could still use \gt and \lt
- everywhere, but ugh. R+
--
Logic is a science of the necessary laws of thought, without which
no employment of the understanding and the reason takes place. --
Immanuel Kant, 1785 Rudolf Adamkovič <salutis@me.com>
Studenohorská 25 84103 Bratislava Slovakia [he/him]
Rudolf Adamkovič <salutis@me.com> writes: FYI: I have just discovered that this bug screwed up a paper I submitted to university this week. In the paper, I wrote the following: "[…] every term $t\in{}q$ with $idf(t)>c$ for some constant $c$ […]", and the "idf(t) > c" part got exported as "idf(t)". I cannot fix the paper at this point. Uh-oh! R+ -- "Logic is a science of the necessary laws of thought, without which no employment of the understanding and the reason takes place." -- Immanuel Kant, 1785 Rudolf Adamkovič <salutis@me.com> Studenohorská 25 84103 Bratislava Slovakia [he/him]
Rudolf,
> FYI: I have just discovered that this bug screwed up a paper I
> submitted to university this week. In the paper, I wrote the
> following: "[…] every term $t\in{}q$ with $idf(t)>c$ for some constant
> $c$ […]", and the "idf(t) > c" part got exported as "idf(t)". I cannot
> fix the paper at this point. Uh-oh!
oof. \(...\) is the way to go.
cheers, Greg
[-- Attachment #1: Type: text/plain, Size: 310 bytes --] Hi Greg, > oof. ... is the way to go. I’m thinking we should perhaps update the docs to more strongly recommend `\( ... \)' over `$ ... $'. So that someone coming from say, Markdown + $-math or (not-La)TeX doesn’t just go “cool, $ works, I’ll keep on using that”. All the best, Timothy
Timothy,
> I’m thinking we should perhaps update the docs to more strongly
> recommend `\( ... \)' over `$ ... $'. So that someone coming from say,
> Markdown + $-math or (not-La)TeX doesn’t just go “cool, $ works, I’ll
> keep on using that”.
i think that would be a helpful change.
cheers, Greg
Greg Minshall <minshall@umich.edu> writes:
> oof. \(...\) is the way to go.
I do not understand. As Max pointed out, inequalities break HTML export in \( and \) as well.
Example:
- \(a<b\)
- \(b>a\)
Org should rewrite < and > to < and > to avoid broken HTML, or as \lt{} and \rt{} in general.
R+
--
"'Contrariwise,' continued Tweedledee, 'if it was so, it might be; and if it were so, it would be; but as it isn't, it ain't. That's logic.'" -- Lewis Carroll, Through the Looking Glass
Rudolf Adamkovič <salutis@me.com>
Studenohorská 25
84103 Bratislava
Slovakia
[he/him]
[-- Attachment #1: Type: text/plain, Size: 746 bytes --] Hi Rudolf, > I do not understand. As Max pointed out, inequalities break HTML export in and as well. > > Example: > > - a<b > - b>a > > Org should rewrite < and > to < and > to avoid broken HTML, or as < and in general. I think we’ve drifted a bit to the differences in processing (where the `\( ... \)' vs `$ ... $' comments are most pertinent), but as you say for valid HTML < and > should be rewritten. I don’t think I’ve seen an issue because MathJax seems to take care of it, but it looks like MathJax is also fine with < and &rt;. As the maintainer for ox-html, I’ll take a look at this. I am exceptionally busy over the next few weeks though, so there may be a brief delay. All the best, Timothy
On 07/10/2021 20:05, Timothy wrote: >> Org should rewrite < and > to < and > to avoid broken HTML, or as < and in general. > > I think we’ve drifted a bit to the differences in processing (where the `\( ... \)' > vs `$ ... $' comments are most pertinent), but as you say for valid HTML < and > > should be rewritten. I don’t think I’ve seen an issue because MathJax seems to > take care of it, but it looks like MathJax is also fine with < and &rt;. "<" and ">" characters are valid only markup elements in HTML (part of tags, comments). MathJax interprets text content. Normally, to add text "<" or ">", "<" or ">" should be used in HTML sources. Browsers may pass "<" and ">" from source to text content if they are totally confused by invalid markup that does not resemble tags or something else. I do not think, it should be abused. I cited MathJax docs just to show a temporary workaround till the bug will be fixed in Org. It is quite strange that Org properly converts "<>&" to entities in text but leaves them as is in math snippets. Unsure whether git history might clarify some reasons of such behavior. On 06/10/2021 14:39, Rudolf Adamkovič wrote > I wrote the following: "[…] every term $t\in{}q$ with $idf(t)>c$ for > some constant $c$ […]", and the "idf(t) > c" part got exported as > "idf(t)". I cannot fix the paper at this point. Uh-oh! If you submitted HTML file, you might suggest to open sources to make it obvious that the mistake was not intentional. "$idf(t)>c$" means "i*d*f(t) > c". A bit more markup required to make "idf" typed in straight font instead of italics and to avoid additional space between characters. It is matter of taste, but "{}" after "\in" looks a bit strange for me. "$t\in q$ is even shorter, "$t \in q$", having the same length, is more readable from my point of view.
Timothy <tecosaur@gmail.com> writes: > […] MathJax seems to take care of it […] From what I understand, MathJax does nothing, for it expects to exit inside of valid HTML. > […] but it looks like MathJax is also fine with < and &rt;. […] Not that I know how ox-html works internally, but FYI, we can also use TeX's native \lt{} and \gt{}. > As the maintainer for ox-html, I’ll take a look at this. Thank you so much in advance! Rudy -- "Logic is a science of the necessary laws of thought, without which no employment of the understanding and the reason takes place." -- Immanuel Kant, 1785 Rudolf Adamkovič <salutis@me.com> Studenohorská 25 84103 Bratislava Slovakia [he/him]
Max Nikulin <manikulin@gmail.com> writes: > If you submitted HTML file, you might suggest to open sources to make it obvious that the mistake was not intentional. One day! The university system switches to a read-only mode at the end of every week, and I cannot open-source anything for two years after the submission. I ended up posting an "errata" comment. > […] "idf" typed in straight font instead of italics and to avoid additional space between characters. Yes, the three letters denote a function name, not a product of three variables. I simplified the snippet for the mailing list. In reality, I typed $\mathrm{idf}(t)>c$, as one should. Thank you for caring! > It is matter of taste, but "{}" after "\in" looks a bit strange for me. "$t\in q$ is even shorter, "$t \in q$", having the same length, is more readable from my point of view. Ha-ha! Yeah, I avoid spaces because they make me think for much too long about where to put them. Knuth would write $t\in q$, like you said, but that looks "unbalanced" to me. Of course, $t \in q$ looks best, but that sends me to back to the "whitespace paralysis" mode. Help wanted. Rudy -- "'Contrariwise,' continued Tweedledee, 'if it was so, it might be; and if it were so, it would be; but as it isn't, it ain't. That's logic.'" -- Lewis Carroll, Through the Looking Glass Rudolf Adamkovič <salutis@me.com> Studenohorská 25 84103 Bratislava Slovakia [he/him]
Rudolf,
> I do not understand. As Max pointed out, inequalities break HTML
> export in \( and \) as well.
my apologies for not having understood where we were in the discussion!
cheers, Greg
Rudolf Adamkovič <salutis@me.com> writes: > Max Nikulin <manikulin@gmail.com> writes: > >> Though I am a bit surprised that Org did not replace characters to >> < and > during export. Perhaps, it is possible to define a >> filter. > > That makes sense, and thank you for the explanation. Ignoring the dead > link in the Org manual, I wonder how this bug can even exist in Org > after 15+ years of development. Some people, including the author of > TeX himself, write TeX without unnecessary whitespace. Strange! Either > way, rearranging bullet points should never break math without any > visual sign inside of Emacs. Thus, this represents a bug in Org. R+ No, it does not. Org mode just passes LaTeX directly to MathJax without changing anything. If you want to blame somebody, you can blame HTML for choosing < and > as its delimiters: see http://docs.mathjax.org/en/latest/input/tex/html.html#html-special-characters -- Nick
On 12/10/2021 08:11, Nick Dokos wrote: > Rudolf Adamkovič writes: >> Max Nikulin writes: >> >>> Though I am a bit surprised that Org did not replace characters to >>> < and > during export. Perhaps, it is possible to define a >>> filter. >> >> That makes sense, and thank you for the explanation. Ignoring the dead >> link in the Org manual, I wonder how this bug can even exist in Org >> after 15+ years of development. Some people, including the author of >> TeX himself, write TeX without unnecessary whitespace. Strange! Either >> way, rearranging bullet points should never break math without any >> visual sign inside of Emacs. Thus, this represents a bug in Org. R+ > > No, it does not. Org mode just passes LaTeX directly to MathJax > without changing anything. If you want to blame somebody, you can > blame HTML for choosing < and > as its delimiters: see > > http://docs.mathjax.org/en/latest/input/tex/html.html#html-special-characters Nick, I am sorry, but I do not see your point. Do you know any reason why Org properly escapes "<>&" in text but transparently passes them to HTML inside LaTeX fragment? Does escaping them everywhere lead to problems? From the referenced document (I posted this link on 2021-10-03): > you need to be careful that your mathematics doesn’t look like HTML tags > to the browser, which parses the page before MathJax gets to see it. ... > you can use the HTML entities <, > and & to encode these > characters so that the browser will not interpret them, but MathJax will. I fail to see any reason to blame HTML. Any text markup language requires some easily typed special characters. Org has one set of them, HTML another one. Export backend should just respect delimeters of the target format. I understand expectations and thus complains of Rudolf. In my opinion he has reasons to be disappointed (and maybe even angry to some degree). It looks like a bug in Org that should be fixed. Workarounds exist but Org should be more reliable.
Max Nikulin <manikulin@gmail.com> writes: > Let's fix at least the link. Old one gives 404 error. Thanks! > Scheme is not changed to https: since the site prefers http: > > curl -I https://docs.mathjax.org/ > HTTP/2 302 It is not erring on my side. Maybe they changed something since last year? -- Ihor Radchenko, 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
On 21/08/2022 12:53, Ihor Radchenko wrote: > Max Nikulin writes: > >> Let's fix at least the link. Old one gives 404 error. curl -I 'http://docs.mathjax.org/en/latest/tex.html' HTTP/1.1 404 Not Found >> Scheme is not changed to https: since the site prefers http: >> >> curl -I https://docs.mathjax.org/ >> HTTP/2 302 > > It is not erring on my side. Maybe they changed something since last year? curl -I https://docs.mathjax.org/ ^^^^^^ HTTP/2 302 date: Sun, 21 Aug 2022 06:16:52 GMT content-type: text/html; charset=utf-8 content-length: 0 location: http://docs.mathjax.org/en/latest/ ^^^^^ response from 188.114.98.205:443
Max Nikulin <manikulin@gmail.com> writes: >> It is not erring on my side. Maybe they changed something since last year? > > curl -I https://docs.mathjax.org/ > ^^^^^^ > HTTP/2 302 > date: Sun, 21 Aug 2022 06:16:52 GMT > content-type: text/html; charset=utf-8 > content-length: 0 > location: http://docs.mathjax.org/en/latest/ > ^^^^^ Hmm. I actually missed that 302 it is not actual error. Applied onto main via 8d93f9b6b. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=8d93f9b6b4e15427d62b84013ee726a0e6760ad9 Feel free to bump any other patch you that did not get a response. While I did track the new patches recently, the ones introduced more than a few months ago and those not being tracked at updates.orgmode.org have likely slipped through the cracks. -- Ihor Radchenko, 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
On 22/08/2022 09:39, Ihor Radchenko wrote:
> Max Nikulin writes:
>
> Hmm. I actually missed that 302 it is not actual error.
>
> Applied onto main via 8d93f9b6b.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=8d93f9b6b4e15427d62b84013ee726a0e6760ad9
Let's try to convince Woof! that it is really
Applied
Max Nikulin <manikulin@gmail.com> writes: >> Applied onto main via 8d93f9b6b. >> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=8d93f9b6b4e15427d62b84013ee726a0e6760ad9 > > Let's try to convince Woof! that it is really > > Applied Ain't working... Bastien, is there any chance that Woof! version used in updates.orgmode.org can be updated? -- Ihor Radchenko, 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
On 23/08/2022 09:32, Ihor Radchenko wrote: > Max Nikulin writes: > >>> Applied onto main via 8d93f9b6b. >>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=8d93f9b6b4e15427d62b84013ee726a0e6760ad9 >> >> Let's try to convince Woof! that it is really >> >> Applied > > Ain't working... > > Bastien, is there any chance that Woof! version used in > updates.orgmode.org can be updated? Or at least, please, clarify which version of https://github.com/bzg/woof/blob/master/resources/md/howto.md should be used for the currently deployed version. Cited message in addition to the "Applied" keyword (no period) had "X-Woof-Patch: applied" header. The complication is that the patch did not start the thread. If I remember correctly, I did not confirmed a bug to not mix a bug and a patch within the single thread. I am confused because just "Applied" with no X-Woof header worked in Max Nikulin to emacs-orgmode. Re: [PATCH] org-protocol.org: updated Linux setup (Gnome) section. Sat, 12 Mar 2022 19:07:53 +0700. https://list.orgmode.org/t0i2er$12l9$1@ciao.gmane.io but neither "Applied" not "Canceled." worked that day in another thread. I did not tried X-Woof-Patch as well, but second message were sent as direct response to the original post: Max Nikulin to emacs-orgmode. Re: [PATCH v3] Fix FAQ entry about mailto links. Sat, 12 Mar 2022 21:35:02 +0700. https://list.orgmode.org/t0ib2n$13f0$1@ciao.gmane.io - sent "Applied" in the body in response to my last message Max Nikulin to emacs-orgmode. Re: [PATCH] Fix FAQ entry about mailto links. Sat, 12 Mar 2022 22:50:25 +0700. https://list.orgmode.org/t0ifg2$l3p$1@ciao.gmane.io
Hi, Ihor Radchenko <yantar92@gmail.com> writes: > Ain't working... Sorry, the Woof! version on updates.orgmode.org is buggy. > Bastien, is there any chance that Woof! version used in > updates.orgmode.org can be updated? It's on the top of my TODO list: I need to finish Woof! rewrite and deploy it on updates.orgmode.org. Ideally, the current database of confirmed bugs and patches would go down to zero before I make the switch. I'll let the list know how things go. -- Bastien
Hi Max, Max Nikulin <manikulin@gmail.com> writes: > Or at least, please, clarify which version of > https://github.com/bzg/woof/blob/master/resources/md/howto.md should > be used for the currently deployed version. This is the documentation of the work-in-progress Woof! rewrite, not the documentation for the old Woof! version on updates.orgmode.org, for which the "doc" was just a section in the README.org : https://github.com/bzg/woof/tree/e40e927b361ca5c7561cc98a02f9b81e519356ad#basic-usage > The complication is that the patch did > not start the thread. The next Woof! version does not suffer from this limitation. -- Bastien
This is a reminder of an old bug. From my point of view it is serious enough, but not release critical due to its age. &<> characters must be escaped as HTML entities when LaTeX snippets and blocks are exported for MathJax Form my year-old notes: - =#+options: tex:verbatim= properly escapes symbols. - There are functions that performs such replacement in ox-html and ox-odt, but `org-format-latex` resides in org.el, so some refactoring and backward compatibility stubs are necessary. This thread was tracked at https://updates.orgmode.org for a minor fix of the manual. On 07/10/2021 22:05, Max Nikulin wrote: > On 07/10/2021 20:05, Timothy wrote: >>> Org should rewrite < and > to < and > to avoid broken HTML, or >>> as < and in general. >> >> I think we’ve drifted a bit to the differences in processing (where >> the `\( ... \)' >> vs `$ ... $' comments are most pertinent), but as you say for valid >> HTML < and > >> should be rewritten. I don’t think I’ve seen an issue because MathJax >> seems to >> take care of it, but it looks like MathJax is also fine with < and >> &rt;. > > "<" and ">" characters are valid only markup elements in HTML (part of > tags, comments). MathJax interprets text content. Normally, to add text > "<" or ">", "<" or ">" should be used in HTML sources. Browsers > may pass "<" and ">" from source to text content if they are totally > confused by invalid markup that does not resemble tags or something > else. I do not think, it should be abused. > > I cited MathJax docs just to show a temporary workaround till the bug > will be fixed in Org. It is quite strange that Org properly converts > "<>&" to entities in text but leaves them as is in math snippets. Unsure > whether git history might clarify some reasons of such behavior.
Max Nikulin <manikulin@gmail.com> writes: > This is a reminder of an old bug. From my point of view it is serious > enough, but not release critical due to its age. > > &<> characters must be escaped as HTML entities when LaTeX snippets and > blocks are exported for MathJax > > Form my year-old notes: > - =#+options: tex:verbatim= properly escapes symbols. > - There are functions that performs such replacement in ox-html and > ox-odt, but `org-format-latex` resides in org.el, so some refactoring > and backward compatibility stubs are necessary. From my understanding, all we need is to fix `org-format-latex' by calling `org-html-encode-plain-text'. Could you please elaborate about refactoring and backward compatibility? -- 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>