LaTeX math export problems
I use Org for producing LaTeX (e.g., all of https://github.com/higham/what-is
is produced from Org source).
I'm finding that Org has trouble parsing some LaTeX math expressions and
I then have to make seemingly arbitrary tweaks to get it to parse correctly.
I thought this might be to do with something in my .emacs, but the same
problem happens with a bare bones Emacs. A simple example is this file:
#
# ex1a_bad.org
\[
\widehat{y} = f(x+\widehat{x}) + \Delta y,
\quad |\widehat{y}| \le \epsilon |y|, \;
|\widehat{x}| \le \epsilon |x|
\]
#
With emacs -q and
This is GNU Emacs 26.3 (build 1, x86_64-w64-mingw32) of 2019-08-29
org-version is a variable defined in 'org.el'. Its value is "9.1.9"
I get as the exported LaTeX:
%
% Created 2020-08-18 Tue 10:08
% Intended LaTeX compiler: pdflatex
\documentclass[11pt]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage{grffile}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{textcomp}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\date{\today}
\title{}
\hypersetup{
pdfauthor={},
pdftitle={},
pdfkeywords={},
pdfsubject={},
pdfcreator={Emacs 26.3 (Org mode 9.1.9)},
pdflang={English}}
\begin{document}
\tableofcontents
$\backslash$[
\widehat{y} = f(x+\widehat{x}) + \(\Delta\) y,
\quad |\widehat{y}| \(\le\) \(\epsilon\) |y|, $\backslash$;
\begin{center}
\begin{tabular}{lll}
\widehat{x} & \(\le\) \(\epsilon\) & x\\
\end{tabular}
\end{center}
$\backslash$]
\end{document}
%
The backslashes are being interpreted literally and the pipes are being
interpreted as a table. Yet this version processes correctly:
#
# ex1a_good.org
\[
\widehat{y} = f(x+\widehat{x}) + \Delta y,
\quad |\widehat{y}| \le \epsilon |y|, \; |\widehat{x}| \le \epsilon |x|
\]
#
I have other simple examples like this one.
The same thing happens with my usual Emacs configuration, which uses Org 9.3.7.
---Nick Higham
Re: LaTeX math export problems
Hello,
Nick Higham writes:
> I thought this might be to do with something in my .emacs, but the same
> problem happens with a bare bones Emacs. A simple example is this file:
>
> #
> # ex1a_bad.org
> \[
> \widehat{y} = f(x+\widehat{x}) + \Delta y,
> \quad |\widehat{y}| \le \epsilon |y|, \;
>|\widehat{x}| \le \epsilon |x|
> \]
> #
In Org, \[...\] is inline markup, so it is weaker than tables.
Therefore, Org cannot see your LaTeX environment. You can use
\begin{equation*}
...
\end{equation*}
instead and lift the ambiguity.
Regards,
--
Nicolas Goaziou
Re: [PATCH] ob-python.el: Fix issue with sessions on remote machines
Hi Christian, Thanks for reporting this and providing a fix! > The function `org-babel-python-evaluate-session' doesn't process temp > file names with `org-babel-process-file-name' before inserting them into > the Python code blocks. This causes a 'No such file' error when the > executing the code blocks on a remote directory. I tested this out and was able to reproduce the bug. > The attached patch fixes this issue, allowing compilation of Python > source blocks with a remote directory, such as :dir /ssh:user@server:/. I tested your patch and it solves the problem. > This is my first patch ever, so please let me know if there's ways I can > improve. The patch is pretty simple and I see no problems with it. Since it is so small, FSF copyright assignment shouldn't be necessary. Also, it looks like you followed all the guidelines on https://orgmode.org/worg/org-contribute.html. I'm fairly novice myself so will wait a couple days in case one of the more experienced folks notices any issues here. But I'll merge this to master by end of week if I don't hear anything.
[PATCH] org-add-planning-info: respect caller's given time [9.3.7 (release_9.3.7-716-g3d4876 @ /home/n/.emacs.d/straight/build/org/)]
The current behavior of `org-add-planning-info' does not include the time of day when it is passed the TIME argument. This is because `org-time-was-given' is initially let-bound to nil during the scope of the function. The attached patch removes that binding and allows the caller to pass the time of day in the above case. An example use case I use with org-capture templates: (defun +org-schedule-relative-to-deadline () "Prompt for optional deadline, then an optional schedule time. The scheduled default time is the deadline." (interactive) (condition-case nil (org-deadline nil) (quit nil)) (let ((org-overriding-default-time (or (org-get-deadline-time (point)) org-overriding-default-time))) ;; works with patch, but without it the time of day is not included in timestamp. (org-schedule nil (org-read-date 'with-time 'to-time nil "SCHEDULE: " org-overriding-default-time >From 2b0840a3963a16b4b92bfdad794a1327aa6f8bd4 Mon Sep 17 00:00:00 2001 From: Nicholas Vollmer Date: Tue, 18 Aug 2020 17:09:50 -0400 Subject: [PATCH] org: (org-add-planning-info): Respect caller's `org-time-was-given' value * lisp/org.el (org-add-planning-info): Respect caller's `org-time-was-given' value Allows programmatically passing a time of day to `org-schedule'. e.g. if one wanted to schedule a task relative to its DEADLINE time of day: (org-schedule nil (org-read-date t t nil "SCHEDULE: " (org-get-deadline-time (point --- lisp/org.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org.el b/lisp/org.el index fb95590fc..aabdaebb9 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -10605,7 +10605,7 @@ among `closed', `deadline', `scheduled' and nil. TIME indicates the time to use. If none is given, the user is prompted for a date. REMOVE indicates what kind of entries to remove. An old WHAT entry will also be removed." - (let (org-time-was-given org-end-time-was-given default-time default-input) + (let (org-end-time-was-given default-time default-input) (when (and (memq what '(scheduled deadline)) (or (not time) (and (stringp time) -- 2.28.0
Bug: org-set-tags-command deletes inherited tags [9.3.7 (9.3.7-18-g093b47-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20200810/)]
Example Org file:
* Parent :foo:bar:baz:
** Child :foo:bar:spam:
Invoking org-set-tags-command with point on Child prepopulates the
minibuffer prompt with only the tags :spam:
This is because org-get-tags doesn't distinguish between inherited only
tags and inherited tags which are also explicitly set on a heading, so
org-set-tags-command treats :foo:bar: as inherited only rather than also
set locally on the heading.
This is undesirable because having tags set directly on a heading has
different semantics even if they are also inherited (e.g., the TAGS
special property, or when headings will be refiled to a different
location later).
Attached patch.
>From 934d65537e46c68c10edbfa2d7140cebfe89d271 Mon Sep 17 00:00:00 2001
From: Allen Li
Date: Tue, 18 Aug 2020 15:34:38 -0700
Subject: [PATCH] org.el: Don't exclude local tags that are also inherited
* lisp/org.el (org-set-tags-command): Don't exclude local tags even if inherited.
---
lisp/org.el | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index fb95590fc..49d7d24f2 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -11880,9 +11880,7 @@ in Lisp code use `org-set-tags' instead."
(org-global-tags-completion-table
(org-agenda-files)))
(or org-current-tag-alist (org-get-buffer-tags)
- (current-tags
- (cl-remove-if (lambda (tag) (get-text-property 0 'inherited tag))
- all-tags))
+ (current-tags (org-get-tags nil t))
(inherited-tags
(cl-remove-if-not (lambda (tag) (get-text-property 0 'inherited tag))
all-tags))
--
2.28.0
Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.22)
of 2020-08-11
Package: Org mode version 9.3.7 (9.3.7-18-g093b47-elpaplus @
/home/ionasal/.emacs.d/elpa/org-plus-contrib-20200810/)
[ANN] Org-collection - (experimental) global minor mode
Hi there, Just wanted to mention that there’s an embryo at https://github.com/Whil-/org-collection for de-globalizing your org mode setup into collections. For those interested in that. This relates to: https://lists.gnu.org/archive/html/emacs-orgmode/2019-12/msg00215.html It’s hasn’t turned out exactly like I envisioned it. Not yet anyways. But it has allowed me to define multiple sets of Org mode configurations that I can work with in parallel. I.e. multiple agenda definitions, TODO-keyword definitions, etc. etc. Documentation is sparse but code is fortunately quite concise and hopefully readable. I’m not sure where exactly to take this next, but thought to share it with the list anyhow. Caveat: I’ve used hooks that are quite new and only available in Emacs 27.1. Luckily that version was “officially” released a few days ago. Final remark: I’m writing embryo above, but this is currently working in my local setup(s). So maybe it’s a bit more than an embryo. Kind regards, and take care Gustav
Re: Bug: org-set-tags-command deletes inherited tags [9.3.7 (9.3.7-18-g093b47-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20200810/)]
Thanks for the patch. Allen Li writes: > Example Org file: > > * Parent :foo:bar:baz: > ** Child :foo:bar:spam: > > Invoking org-set-tags-command with point on Child prepopulates the > minibuffer prompt with only the tags :spam: > > This is because org-get-tags doesn't distinguish between inherited only > tags and inherited tags which are also explicitly set on a heading, so > org-set-tags-command treats :foo:bar: as inherited only rather than also > set locally on the heading. > > This is undesirable because having tags set directly on a heading has > different semantics even if they are also inherited (e.g., the TAGS > special property, or when headings will be refiled to a different > location later). I agree, that's undesirable and likely unintended. > Subject: [PATCH] org.el: Don't exclude local tags that are also inherited > > * lisp/org.el (org-set-tags-command): Don't exclude local tags even if > inherited. > --- > lisp/org.el | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) It'd be good to add something along the lines of your example as a case in test-org/set-tags-command. > diff --git a/lisp/org.el b/lisp/org.el > index fb95590fc..49d7d24f2 100644 > --- a/lisp/org.el > +++ b/lisp/org.el > @@ -11880,9 +11880,7 @@ in Lisp code use `org-set-tags' instead." > (org-global-tags-completion-table > (org-agenda-files))) >(or org-current-tag-alist (org-get-buffer-tags) > -(current-tags > - (cl-remove-if (lambda (tag) (get-text-property 0 'inherited > tag)) > - all-tags)) > +(current-tags (org-get-tags nil t)) > (inherited-tags > (cl-remove-if-not (lambda (tag) (get-text-property 0 'inherited > tag)) > all-tags)) That looks good as far as fixing the misbehavior you report. I wonder though whether there's a deeper org-get-tags issue here worth considering. Its documentation says ... the returned list of tags contains tags in this order: file tags, tags inherited from parent headlines, local tags. But it's not specified what happens when a tag is both local and inherited. The current implementation drops the local tag variant through its delete-dups call: (delete-dups (append (org-remove-uninherited-tags itags) ltags)) I would have expected the local tag to get priority here. If that were the case (e.g., something like below), that would also solve the issue you describe. Thoughts? -- >8 -- diff --git a/lisp/org.el b/lisp/org.el index fb95590fc..3dac42b7b 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -12310,8 +12310,10 @@ (defun org-get-tags (&optional pos local) (org--get-local-tags)) itags))) (setq itags (append org-file-tags itags)) -(delete-dups - (append (org-remove-uninherited-tags itags) ltags +(nreverse + (delete-dups + (nreverse (nconc (org-remove-uninherited-tags itags) + ltags)) (defun org-get-buffer-tags () "Get a table of all tags used in the buffer, for completion."
