Re: [9.4] Fixing logbook visibility during isearch
Kévin Le Gouguec writes: > Since the changes in Org 9.4 aimed at improving performance, is there a > test case somewhere in the "Mitigating the poor Emacs performance on > huge org files" thread that could help ensure that a tentative fix will > not degrade performance? The first message in the thread ;) I believe it was also used to benchmark the change in 9.4. >> [3] See the attached org file in my Emacs bug report: >> https://lists.gnu.org/archive/html/bug-gnu-emacs/2019-04/txte6kQp35VOm.txt Or you can ask me to test. That example file is my stripped someday list, which grew to much larger size since the time I created that example. Best, Ihor
Re: LaTeX fragments not being generated due to extra * in tikz env
Hi,
I introduced the change that broke the behavior. The attached patch
seems to fix the issue for me, does it look reasonable?
Thanks,
thibault
On 2020-12-09T13:16:19-0500, Jeremie Juste wrote:
Hello,
Thanks for reporting. Indeed this is an issue that hasn't been fixed
yet. This is the case for most latex environments
My solution is here
https://www.mail-archive.com/emacs-orgmode@gnu.org/msg129974.html
but consider also the idea behind the star
https://www.mail-archive.com/emacs-orgmode@gnu.org/msg129976.html
I will try to submit a patch soon.
Best regards,
Jeremie
On Tuesday, 8 Dec 2020 at 20:57, 10cadr wrote:
> I was trying out the new option tex:dvipng. The HTML result was a image
> with the tikz code.
>
> Turns out, debugging and telling the fragment processor not to delete the
> files, what org generates for the tikz fragment is:
>
> \begin{tikzpicture*}
>
> Removing the astherisk would make it work without any workarounds.
>
> How I got around this was
>
> #+LATEX_HEADER: \usepackage{environ,amsmath,multicol}
> #+LATEX_HEADER:
>
\NewEnviron{tikzpicture*}[1][]{\begin{tikzpicture}[#1]\BODY\end{tikzpicture}}
>
> Possibly fixing this issue, will make cross formats much easier.
--
Jeremie Juste
From f5122a85b0170f17be103400b5f910030df806c4 Mon Sep 17 00:00:00 2001
From: thibault
Date: Thu, 10 Dec 2020 13:26:08 -0500
Subject: [PATCH] Fix non-math environment export
* ox-html.el (org-html-latex-environment): Prevent addition of * to
non-math environments. Added * is used for math environments to
replace latex equation numbering by org labels for html linking.
---
lisp/ox-html.el | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index d2f24f5c6..40024c70b 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -2933,7 +2933,9 @@ CONTENTS is nil. INFO is a plist holding contextual information."
((assq processing-type org-preview-latex-process-alist)
(let ((formula-link
(org-html-format-latex
- (org-html--unlabel-latex-environment latex-frag)
+ (if (eq nil (org-html--math-environment-p latex-environment))
+ latex-frag
+ (org-html--unlabel-latex-environment latex-frag))
processing-type info)))
(when (and formula-link (string-match "file:\\([^]]*\\)" formula-link))
(let ((source (org-export-file-uri (match-string 1 formula-link
--
2.29.2
Re: Release Org 9.4.2
i just wanted to say thanks to everybody who maintains org. somebody said a counter for donations might be useful even if nobody collects it. i am not able to follow this discussion closely for health reasons, but one possibility, which you can reject if you like, but which i mention because nobody has mentioned it yet, is to have that counter go to e.g. biomedical research or another good cause. then org becomes associated with "help find a treatment for (insert disease]"or similar. i know from the other end [viz. biomedical research desperately needed] that such things can be used for very good purposes very efficiently. the scientists eat pizza, not fancy food, and they think hard about making their assays efficient etc. and i know that it can be motivating to donate to such things. to me at least. i could suggest a few that are likely highly relevant to long covid and one or more of my own serious medical issues that are not getting adequate research. or maintainers could choose. On 12/17/20, Greg Minshall wrote: > Eric, > >> Sure, and I do use it this way, but I had the impression that it was the >> non-git aspects that were being put forward as being somehow helpful. I >> could be wrong. > > i'm not a git-spert. but, the "pull requests" mechanism and "issues" > (but reports), are maybe bits of git*.com that people like? (i find > them useful myself.) > > Greg > > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Bug: org-element does not recognize table.el tables [9.4 (release_9.4-53-g23f941 @ /home/nick/elisp/org-mode/lisp/)]
Consider an Org mode file with a table.el table (which I made by
first constructing an Org mode table and then usind `C-c ~' to convert it):
--8<---cut here---start->8---
* table.el table
++++
| a | b | c |
++++
| 1 | 2 | 3 |
++++
| 4 | 5 | 6 |
++++
| 7 | 8 | 9 |
++++
| 10 | 11 | 12 |
++++
--8<---cut here---end--->8---
Trying to export to LaTeX produces pretty mangled output.
It turns out that when in
`org-latex-table', (org-element-property :type table) returns `org', so
it thinks it's an Org mode table and calls `org-latex--org-table' to
process it, producing output like this:
--8<---cut here---start->8---
\sout{}\sout{}
\begin{center}
\begin{tabular}{lll}
a & b & c\\
\end{tabular}
\end{center}
\sout{}\sout{}
\begin{center}
\begin{tabular}{rrr}
1 & 2 & 3\\
\end{tabular}
\end{center}
\sout{}\sout{}
...
\begin{center}
\begin{tabular}{rrr}
10 & 11 & 12\\
\end{tabular}
\end{center}
\sout{}\sout{}
--8<---cut here---end--->8---
Evaluating `(org-element-at-point)' returns `(paragraph ...)' all along
the top line and `(table ( :type org ))' when the cursor is at
the beginning of the `a b c' line.
Emacs : GNU Emacs 28.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.13,
cairo version 1.16.0)
of 2020-10-30
Package: Org mode version 9.4 (release_9.4-53-g23f941 @
/home/nick/elisp/org-mode/lisp/)
--
Nick
Re: error when archiving two subtrees in a row
I actually hadn't used the archive command in quite a while, so not sure when the behavior in my situation changed. It does make sense though that it might have something to do with the file being stored in a dropbox folder. Anyway, (setq org-archive-subtree-save-file-p nil) in the init file fixes it. Thanks Kyle! On Thu, Dec 17, 2020 at 12:37 AM Kyle Meyer wrote: > Ian Garmaise writes: > > > When I archive one subtree (C-c $), the first one succeeds. > > The second archive operation fails with a permission denied error as > shown > > in the messages buffer: > [...] > > Noticed this yesterday. Updated org and all packages, then tried it > again > > today, was able to reproduce it easily > > Hmm, was that an update from 9.3.* or earlier? 9.4 came with a new > option org-archive-subtree-save-file-p. With the default value, the > file is saved when archiving from an Org buffer but not the agenda. > Before 9.4 [*], the file was never saved, so you could set > org-archive-subtree-save-file-p to nil to restore the pre-9.4 behavior. > > That should sidestep the issue, though I don't know why you're hitting. > I'm guessing you only see it with dropbox files? > > [*] Going farther back, the behavior was to always save. That changed > in 9.1.4 63f6e851b (Do not save target buffer after archiving > subtree, 2017-11-25). > -- = Ian Garmaise Consultant Phorix Solutions Group ia...@phorixsol.com Toronto cell: 416.432.2251 NYC: 917.512.9535 https://www.linkedin.com/in/igarmaise/ http://www.PhorixSol.com
Re: W3C violations in Org's HTML export
I don't think this should be forgotten about, so I'm adding it to https://updates.orgmode.org/#help for now.
[PATCH] A proposal to add LaTeX attributes to verse blocks
(Sorry, due to a mistake, the text of my message did not appear in my previous
email)
Hi,
I would like to propose this patch to add some LaTeX attributes to the verse
block,
especially to be able to apply certain features from the verse.sty package,
which is an
extension (widely used in Humanities) of the standard LaTeX 'verse' environment.
These attributes would be:
- `:lines' to add verse numbers, according to any numbering sequence
- `:center' to apply the optical centering of the poem, which is a typographic
convention
whereby a poem or a group of verses is centered on the page, taking the width
of the
longest verse as a reference. In fact, optical centering is the correct
arrangement of
verses in a document.
- `:versewidth' which expects a text string that is the longest verse of the
poem,
required when applying the `:center' attribute.
As I said, these three attributes require the LateX package verse.sty. A fourth
`:options'
attribute would be used to add arbitrary code within the verse environment.
Consider this complete example with Shakespeare's first sonnet:
#+begin_src org
,#+ATTR_LaTeX: :center t :options \small :lines 5
,#+ATTR_LaTeX: :versewidth Feed’st thy light’st flame with self-substantial
fuel,
,#+begin_verse
From fairest creatures we desire increase,
That thereby beauty’s rose might never die,
But as the riper should by time decrease,
His tender heir mught bear his memeory:
But thou, contracted to thine own bright eyes,
Feed’st thy light’st flame with self-substantial fuel,
Making a famine where abundance lies,
Thyself thy foe, to thy sweet self too cruel.
Thou that art now the world’s fresh ornament
And only herald to the gaudy spring,
Within thine own bud buriest thy content
And, tender churl, makest waste in niggarding.
Pity the world, or else this glutton be,
To eat the world’s due, by the grave and thee.
,#+end_verse
#+end_src
when exporting to LaTeX we get:
#+begin_src latex
\settowidth{\versewidth}{Feed’st thy light’st flame with self-substantial fuel,}
\begin{verse}[\versewidth]
\poemlines{5}
\small
>From fairest creatures we desire increase,\\
That thereby beauty’s rose might never die,\\
But as the riper should by time decrease,\\
His tender heir mught bear his memeory:\\
But thou, contracted to thine own bright eyes,\\
Feed’st thy light’st flame with self-substantial fuel,\\
Making a famine where abundance lies,\\
Thyself thy foe, to thy sweet self too cruel.\\
Thou that art now the world’s fresh ornament\\
And only herald to the gaudy spring,\\
Within thine own bud buriest thy content\\
And, tender churl, makest waste in niggarding.\\
Pity the world, or else this glutton be,\\
To eat the world’s due, by the grave and thee.\\
\end{verse}
#+end_src
In an attached image I send a screenshot with the typographic result
And finally, this is the patch I would propose
#+begin_src diff
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 2a14b25d5..bc6b64e78 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3506,6 +3506,16 @@ channel."
"Transcode a VERSE-BLOCK element from Org to LaTeX.
CONTENTS is verse block contents. INFO is a plist holding
contextual information."
+(let*
+ ((lin (org-export-read-attribute :attr_latex verse-block :lines))
+ (opt (org-export-read-attribute :attr_latex verse-block :options))
+ (cent (org-export-read-attribute :attr_latex verse-block :center))
+ (attr (concat
+ (if cent "[\\versewidth]" "")
+ (if lin (format "\n\\poemlines{%s}" lin) "")
+ (if opt (format "\n%s" opt) "")))
+ (versewidth (org-export-read-attribute :attr_latex verse-block
:versewidth))
+ (vwidth-attr (if versewidth (format "\\settowidth{\\versewidth}{%s}\n"
versewidth) "")))
(concat
(org-latex--wrap-label
verse-block
@@ -3513,7 +3523,9 @@ contextual information."
;; character and change each white space at beginning of a line
;; into a space of 1 em. Also change each blank line with
;; a vertical space of 1 em.
-(format "\\begin{verse}\n%s\\end{verse}"
+(format "%s\\begin{verse}%s\n%s\\end{verse}"
+ vwidth-attr
+ attr
(replace-regexp-in-string
"^[ \t]+" (lambda (m) (format "\\hspace*{%dem}" (length m)))
(replace-regexp-in-string
@@ -3524,7 +3536,7 @@ contextual information."
info)
;; Insert footnote definitions, if any, after the environment, so
;; the special formatting above is not applied to them.
- (org-latex--delayed-footnotes-definitions verse-block info)))
+ (org-latex--delayed-footnotes-definitions verse-block info
#+end_src
Regards,
Juan Manuel
Re: Release Org 9.4.2
Eric, > Sure, and I do use it this way, but I had the impression that it was the > non-git aspects that were being put forward as being somehow helpful. I > could be wrong. i'm not a git-spert. but, the "pull requests" mechanism and "issues" (but reports), are maybe bits of git*.com that people like? (i find them useful myself.) Greg
Re: [9.4] Fixing logbook visibility during isearch
Ihor Radchenko writes: > You will probably need to implement this from scratch (or use the > feature/org-fold branch from github.com/yantar92/org). Gotcha. TBH I don't know if I'll have the time to cook up a patch before 27.2 is released; all the same, I appreciate you taking the time to explain all this. Since the changes in Org 9.4 aimed at improving performance, is there a test case somewhere in the "Mitigating the poor Emacs performance on huge org files" thread that could help ensure that a tentative fix will not degrade performance?
Re: Release Org 9.4.2
On Wednesday, 16 Dec 2020 at 16:13, Loris Bennett wrote: > But even if a project is hosted on GitHub, you can still interact with > it just via Emacs, it is still Git after all. Sure, and I do use it this way, but I had the impression that it was the non-git aspects that were being put forward as being somehow helpful. I could be wrong. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.2-143-gc822c8
