Re: Citations: non-page locators placed in front of citation
Am Sonntag, dem 10. Oktober 2021 schrieb András Simonyi: > looks like an Org (oc-csl) side locator parsing problem to me, because > using the alternative [cite:@saenger2013gsr para. 12 Rn. 488] form I > seem to get the correct result. Can it be a regex matching problem > with the paragraph symbols? Now it’s getting wild. If I use Das ist ein Test [cite:@saenger2013gsr para. 12 Rn. 488]. Then it exports to this: Saenger, Gesellschaftsrecht, 2. Aufl. (2013), ¶¶ 12 Rn. 488 The locator’s position is correct, but it now has two pilcrow signs ¶ instead of one section sign §. I have never seen that in citations, but maybe it is actually correct for other disciplines than mine. FWIW, if I use Das ist ein Test [cite:@saenger2013gsr line 12 Rn. 488]. it yields the correct Saenger, Gesellschaftsrecht, 2. Aufl. (2013), Z. 12 Rn. 488 (with "Z." being short for "Zeile", i.e. "line" in German). So this appears to be a problem specifically with the § sign? -quintus -- Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite Passau, Deutschland | kont...@guelker.eu| O<
Re: Patch to allow adjusting latex fragment display scale factor
Matt Huszagh writes: > I've created a patch to allow adjusting the scale factor used for inline > latex image fragments. This involves a customizable variable that can > either be set to a scale factor (defaults to 1.0) or a function that > evaluates to a scale factor. > > This feature is in addition to the existing scale factor adjustment > capability provided by `org-preview-latex-process-alist' through > `:image-size-adjust'. Wherease image-size-adjust performs scaling at the > time of image generation, the new change performs it during > display. This can lead to significant time saving and suffers no loss of > quality for vector graphics. > > As an example of use, I have several functions for changing frame > scaling. I've added > > (if (eq major-mode 'org-mode) > (progn > (org-clear-latex-preview) > ;; 16 corresponds to the C-u C-u arg prefix. > (org-latex-preview 16))) > > to these functions so that changing the frame scaling also > correspondingly changes the latex preview/fragment scaling to match the > new size of the surrounding text. Because of this new feature, this > change is effectively instantaneous for reasonably numbers of > overlays. Obviously, something similar could be done for > `text-scale-adjust' (e.g., through `advice-add'). > > Feedback appreciated. Apologies, the patch I sent is slightly wrong. The line numbers also reflect an earlier patch I made. Here is a corrected version. >From 3c0e74a8659edb52c1200a02f8a20216b348c4ac Mon Sep 17 00:00:00 2001 From: Matt Huszagh Date: Sun, 10 Oct 2021 21:20:31 -0700 Subject: [PATCH] org.el: Allow customizing overlay-put scale factor * lisp/org.el (org-latex-fragment-scale): Add customizable variable that is equal to or evaluates to a scale factor used to scale inline latex fragments. (org--make-preview-overlay): Adjust latex fragment overlay generation to account for the new custom scale factor. --- lisp/org.el | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/lisp/org.el b/lisp/org.el index 405f0f0f9..052212efb 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -320,6 +320,15 @@ identifier." :version "24.1" :group 'org-id) +(defcustom org-latex-fragment-scale 1.0 + "Scaling factor used for LaTeX image fragments. +This can either be a number or a function that takes the image +data and image type as parameters and evaluates to a number. The +function can be useful for context-aware scaling, such as setting +the scale factor to be consistent with the surrounding text size." + :type '(number function) + :group 'org) + ;;; Version (org-check-version) @@ -15936,7 +15945,13 @@ as a string. It defaults to \"png\"." (delete-overlay o (overlay-put ov 'display - (list 'image :type imagetype :file image :ascent 'center + (list 'image + :type imagetype + :file image + :ascent 'center + :scale (if (functionp org-latex-fragment-scale) + (funcall org-latex-fragment-scale image imagetype) +org-latex-fragment-scale) (defun org-clear-latex-preview ( beg end) "Remove all overlays with LaTeX fragment images in current buffer. -- 2.31.1
Patch to allow adjusting latex fragment display scale factor
Hi, I've created a patch to allow adjusting the scale factor used for inline latex image fragments. This involves a customizable variable that can either be set to a scale factor (defaults to 1.0) or a function that evaluates to a scale factor. This feature is in addition to the existing scale factor adjustment capability provided by `org-preview-latex-process-alist' through `:image-size-adjust'. Wherease image-size-adjust performs scaling at the time of image generation, the new change performs it during display. This can lead to significant time saving and suffers no loss of quality for vector graphics. As an example of use, I have several functions for changing frame scaling. I've added (if (eq major-mode 'org-mode) (progn (org-clear-latex-preview) ;; 16 corresponds to the C-u C-u arg prefix. (org-latex-preview 16))) to these functions so that changing the frame scaling also correspondingly changes the latex preview/fragment scaling to match the new size of the surrounding text. Because of this new feature, this change is effectively instantaneous for reasonably numbers of overlays. Obviously, something similar could be done for `text-scale-adjust' (e.g., through `advice-add'). Feedback appreciated. Matt >From 8247947aa6141cde9c58205e0266f0e674226f95 Mon Sep 17 00:00:00 2001 From: Matt Huszagh Date: Sun, 10 Oct 2021 21:20:31 -0700 Subject: [PATCH] org.el: Allow customizing overlay-put scale factor * lisp/org.el (org-latex-fragment-scale): Add customizable variable that is equal to or evaluates to a scale factor used to scale inline latex fragments. (org--make-preview-overlay): Adjust latex fragment overlay generation to account for the new custom scale factor. --- lisp/org.el | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/lisp/org.el b/lisp/org.el index dbc288a3c..f5e9ff8d1 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -388,6 +388,15 @@ text." :type '(symbol function integer) :group 'org) +(defcustom org-latex-fragment-scale 1.0 + "Scaling factor used for LaTeX image fragments. +This can either be a number or a function that takes the image +data and image type as parameters and evaluates to a number. The +function can be useful for context-aware scaling, such as setting +the scale factor to be consistent with the surrounding text size." + :type '(number function) + :group 'org) + ;;; Version (org-check-version) @@ -16007,7 +16016,13 @@ as a string. It defaults to \"png\"." (delete-overlay o (overlay-put ov 'display - (list 'image :type imagetype :file image :ascent ascent) + (list 'image + :type imagetype + :file image + :ascent ascent + :scale (if (functionp org-latex-fragment-scale) +(funcall org-latex-fragment-scale image imagetype) + org-latex-fragment-scale)) (defun org-clear-latex-preview ( beg end) "Remove all overlays with LaTeX fragment images in current buffer. -- 2.31.1
Re: [BUG] Consecutive emphasis markers only work every other time [9.5 (9.5-??-cc2490a70 @ /home/joe/.emacs.d/.local/straight/build-27.1/org/)]
Joseph Peterson writes: > > > Steps to reproduce: > Enter org mode (I am on cc2490a7061955395c4f5a1a23a088044554a2f7) > Type *bold* *bold* *bold* > Notice that the second instance is not bolded while the first and third > are. Confirmed. Thanks for reporting! The problem was introduced in fa315986a. This particular issues can be fixed by -(goto-char (match-end 0)) +(goto-char (match-beginning 5)) However, I afraid that the whole fa315986a idea may not be useful. Moving to the end of emphasis upon fontification will break any kind of nesting (like *bold /italic end bold* end italic/). This is probably more severe compared to arcane scenario in https://orgmode.org/list/87fsujp7mc@web.de Best, Ihor
bug#45915: 29.0.50; deletechar distorts org-table
I confirm that there is still problem with org-table on Emacs 29.0.50 with org-version 9.5. I created a function to produce the problem as shown below. Can you try again? (defun emacs-bug-reproduce-45915 () "Reproduce bug#45915." ;; (gnus-read-ephemeral-emacs-bug-group 45915) (interactive) (with-current-buffer (get-buffer-create "*temp buffer*") (erase-buffer) (require 'org) (orgtbl-mode 1) (insert (format "emacs-version: %s, org-version: %s\n" emacs-version org-version)) (insert "| | rownames | | / | | |---+--| | | a|")) (switch-to-buffer-other-window "*temp buffer*") (execute-kbd-macro (kbd "M-< C-n C-n C-n C-n C-f C-f")) (message "I will hit S-.") (sit-for 2) (execute-kbd-macro (kbd "S-")) (message "I will hit .") (sit-for 2) (execute-kbd-macro (kbd "")) (message "I will call previous-line.") (sit-for 2) (call-interactively 'previous-line)) ;;; (call-interactively 'emacs-bug-reproduce-45915) >>> I confirm that there still is following problem on 27.1.91. >>> Could someone take a look and show me work around? >> >> I cannot reproduce this with latest Org stable version 9.4.5. >> >> Can you try again and report? > > I downloaded Org 9.4.5 and reproduced the problem on 26.3, 27.2, > and 28.0.50. Here is a recipe again. > >> On certain condition, typing distorts alignment of >> a table. Then, typing moves point to previous line but far >> right position (column 14 instead of column 2). >> >> | | rownames | | | rownames | >> | / | | | / | | >> |---+--| -> |---+--| >> | / | a| | | a| >> >> Here is a recipe to reproduce the glitch started from emcas -Q. >> >> 1. Create a buffer with (text-mode) and yank following table. >> >> | | rownames | >> | / | | >> |---+--| >> | | a| >> >> 2. (progn (require 'org) (call-interactively 'orgtbl-mode)) >> 3. Move point to the first column and the third line with letter 'a'. >> 4. Hit . >> 5. Hit . >> 6. Hit .
Re: Patch to align baseline of latex fragments and surrounding text
Matt Huszagh writes: > I've created a patch to align the baseline of latex image fragments to > the surrounding text. The patch consists of several parts. First, it > adds a customizable variable that can be set to a user supplied function > to compute the value of :ascent passed to `overlay-put'. It can also be > set to a symbol (e.g., 'center, which is the current setting and still > the default), or an integer (:ascent can take an integer > percentage). The patch also modifies `org--make-preview-overlay' to use > this new variable. > > The other part of the patch is a new function that computes the correct > value for :ascent from an SVG file. > > Unfortunately, this isn't a general-purpose solution to baseline text > alignment. It currently only works with SVG images and requires that > these SVG images encode the text baseline in the viewBox attribute (I've > explained in the function documentation how to achieve this). > > I was not initially planning to include the function because it only > works in certain special cases (though if you setup your SVG image > generation as I've described in the documentation it should work > correctly for all of your LaTeX fragments). However, I ultimately > decided it was beneficial to include it for several reasons: (1) it > would not be obvious for many users how to write this function on their > own, (2) by including it, others can improve upon it, and (3) I tried to > minimize corner cases by leaving the default value as 'center and having > the function return 'center whenever it detects an incorrect :ascent > value. I should also mention that I've tested this for different image scaling factors (`:image-size-adjust' in `org-preview-latex-process-alist') and it works regardless of the scale factor. That is, the baseline will be correctly aligned irrespective of the scale factor you set (though obviously the text median (https://en.wikipedia.org/wiki/Baseline_(typography))) will only match the surrounding text for the correct scaling factor. Matt
Patch to align baseline of latex fragments and surrounding text
Hello,
I've created a patch to align the baseline of latex image fragments to
the surrounding text. The patch consists of several parts. First, it
adds a customizable variable that can be set to a user supplied function
to compute the value of :ascent passed to `overlay-put'. It can also be
set to a symbol (e.g., 'center, which is the current setting and still
the default), or an integer (:ascent can take an integer
percentage). The patch also modifies `org--make-preview-overlay' to use
this new variable.
The other part of the patch is a new function that computes the correct
value for :ascent from an SVG file.
Unfortunately, this isn't a general-purpose solution to baseline text
alignment. It currently only works with SVG images and requires that
these SVG images encode the text baseline in the viewBox attribute (I've
explained in the function documentation how to achieve this).
I was not initially planning to include the function because it only
works in certain special cases (though if you setup your SVG image
generation as I've described in the documentation it should work
correctly for all of your LaTeX fragments). However, I ultimately
decided it was beneficial to include it for several reasons: (1) it
would not be obvious for many users how to write this function on their
own, (2) by including it, others can improve upon it, and (3) I tried to
minimize corner cases by leaving the default value as 'center and having
the function return 'center whenever it detects an incorrect :ascent
value.
Let me know what you think!
Best
Matt
>From 6c33fa1875cc169616d878b59054d50980f741f3 Mon Sep 17 00:00:00 2001
From: Matt Huszagh
Date: Sun, 10 Oct 2021 15:46:05 -0700
Subject: [PATCH] org--make-preview-overlay: Add ability to set vertical
alignment of latex fragments
* lisp/org.el (org--match-text-baseline-ascent): Add function that
computes the value of :ascent to match the baseline of the fragment to
the surrounding text.
(org-latex-fragment-overlay-ascent): Add custom variable that allows a
function to be used to compute the value of :ascent.
(org--make-preview-overlay): Incorporate the custom variable.
---
lisp/org.el | 89 +++--
1 file changed, 80 insertions(+), 9 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index 405f0f0f9..dbc288a3c 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -320,6 +320,74 @@ identifier."
:version "24.1"
:group 'org-id)
+(defun org--match-text-baseline-ascent (imagefile imagetype)
+ "Set :ascent to match the text baseline of an image to the surrounding text.
+IMAGEFILE is the path of the image file and IMAGETYPE is the
+image file type.
+
+This function currently only works for SVG images (defaulting to
+'center otherwise). It also requires that the SVG's viewbox is
+correctly set according to the text baseline position.
+Specifically, it computes
+
+ascent = 100 * -min-y / height
+
+where min-y and height are taken from the viewbox. If this
+computation returns a non-sensical value (below 0 or above 100),
+it will return 'center instead.
+
+It's possible to include text baseline information in the viewbox
+by using \\documentclass[preview]{standalone} in the input LaTeX
+file, compiling first to DVI and then converting this to an SVG
+image with dvisvgm.
+
+For example,
+
+(setq my-dvisvgm
+ '(my-dvisvgm :programs (\"latex\" \"dvisvgm\")
+ :description \"dvi > svg\"
+ :message \"you need to install latex and dvisvgm.\"
+ :use-xcolor t
+ :image-input-type \"dvi\"
+ :image-output-type \"svg\"
+ :latex-compiler (\"latex -output-directory=%o %f\")
+ :image-converter (\"dvisvgm --no-fonts --exact-bbox -c %S -o %O %f\")))
+
+(add-to-list 'org-preview-latex-process-alist my-dvisvgm)
+(setq org-preview-latex-default-process 'my-dvisvgm)
+
+(setq org-format-latex-header
+ \"\\documentclass[preview]{standalone}
+ [PACKAGES]
+ [DEFAULT-PACKAGES]\")"
+ (if (eq imagetype 'svg)
+ (let* ((viewbox (split-string
+ (xml-get-attribute (car (xml-parse-file imagefile)) 'viewBox)))
+ (min-y (string-to-number (nth 1 viewbox)))
+ (height (string-to-number (nth 3 viewbox)))
+ (ascent (round (* -100 (/ min-y height)
+(if (or (< ascent 0) (> ascent 100))
+'center
+ ascent))
+'center))
+
+(defcustom org-latex-fragment-overlay-ascent 'center
+ "Value of :ascent used for LaTeX image fragments.
+Org uses `overlay-put' to overlay LaTeX image fragments on inline
+math. `overlay-put' takes an :ascent parameter that can specify
+the vertical offset of this image fragment. See the 'Image
+Descriptors' section of the elisp manual for more information.
+
+If this variable is a symbol or integer it will be passed
+directly to :ascent. It can also be a function that takes the
+image file as an argument. The
A minor suggestion about formatting citations
Date: Mon, 11 Oct 2021 04:36:56 +0530 From: Vikas Rawal To: org-mode mailing list Subject: A minor suggestion about formatting citations Organisation: CESP, Jawaharlal Nehru University, New Delhi I find it works better for me if I insert spaces between multiple citations. For example: [cite: @john56; @john35; @bruce2021] rather than [cite:@john56;@john35;@bruce2021]. The of advantage is that if I am citing many references in one place, and use fill-paragraph/auto-fill, they wrap nicely. As far as I can see, having spaces in between works just fine. If this does not break anything, should this be the recommended practice for the org-cite-insert-processors? Vikas
Re: org-beamer empty titles
Le 10/10/2021 à 22:04, Eric S Fraga a écrit : > On Sunday, 10 Oct 2021 at 17:44, Joseph Vidal-Rosset wrote: >> I reply to my question about org-bullets: the reply is no. Registering >> an empty title section delete the space and then the export frame does >> not work. :( > > I am not sure what you mean by "registering". You can type "* " > directly to create an empty headline, can you not? > > In any case, you could try the following maybe: > > * :sometag: > > or, if getting desperate, resort to some LaTeX magic: > > * @@latex:}%@@ > > -- > : Eric S Fraga via Emacs 28.0.60, Org release_9.5-93-gd87250 > : Latest paper written in org: https://arxiv.org/abs/2106.05096 > Many thanks Eric, the magic LaTeX solution works (but why?). "Registering" means "Ctrl-x-s" i.e. saving a file: when I save the org file, the blank space disappears... Best wishes, Jo.
Re: [org-cite] add convention for direct commands, process for adding mappings to export processor(s)?
On Sun, Oct 10, 2021 at 4:41 PM Nicolas Goaziou wrote: > >> And if we were to add this, we'd still need to answer my first > >> question: when and how to add specific style/variant mappings to the > >> oc processors. > > It is possible to send a patch if it is something useful. Some > processors (probably only biblatex at this point, we probably cover > everything in natbib) may also introduce a customizable variable for > user-defined styles. Ah yes; that's a better solution. And I agree; it mostly makes sense for biblatex (though I saw someone on reddit asking about natbib \bibentry, which is what reminded me about this). It's not needed for oc-csl, because of the tight integration of that with citeproc-el. Bruce
Re: Citations: non-page locators placed in front of citation
Dear All, On Sun, 10 Oct 2021 at 22:11, Nicolas Goaziou wrote: > > Then, this may be a bug in Citeproc library itself. I suggest to report > it upstream. looks like an Org (oc-csl) side locator parsing problem to me, because using the alternative [cite:@saenger2013gsr para. 12 Rn. 488] form I seem to get the correct result. Can it be a regex matching problem with the paragraph symbols? best wishes, András
Re: [org-cite] add convention for direct commands, process for adding mappings to export processor(s)?
Hello, "Bruce D'Arcus" writes: >> The current list of styles and variants included in the oc export >> processors was a first step, with a goal to provide a solid starting >> point, and citations that are more-or-less portable across the >> backends. >> >> But that raises an obvious question: what next? Are we at next already? >> I'd like, for example, to suggest adding "noauthor/bare" -> "cite*" to >> oc-biblatex. Done. >> I also think we should add a way for users to use a direct command for >> natbib and biblatex. [...] >> Perhaps some prefix for a style that signals to pass on directly for a >> specific export processor; like [cite/blx+footcite ...]. I'm not too keen on extending the citation syntax. >> In that case, the oc-biblatex processor would pass that command on as >> is, but other processors would ignore it, and use the default >> instead. This is the point of styles. We could allow custom ones. >> And if we were to add this, we'd still need to answer my first >> question: when and how to add specific style/variant mappings to the >> oc processors. It is possible to send a patch if it is something useful. Some processors (probably only biblatex at this point, we probably cover everything in natbib) may also introduce a customizable variable for user-defined styles. Regards, -- Nicolas Goaziou
Re: Citations: non-page locators placed in front of citation
Am Sonntag, dem 10. Oktober 2021 schrieb Nicolas Goaziou: > Then, this may be a bug in Citeproc library itself. I suggest to report > it upstream. Done: https://github.com/andras-simonyi/citeproc-el/issues/57 -quintus -- Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite Passau, Deutschland | kont...@guelker.eu| O<
Re: Citations: non-page locators placed in front of citation
Hello, M. ‘quintus’ Gülker writes: > I however do not think the problem is related to the NBSP. I just > retried without it, and the § sign is still pulled towards the front. > I also retried with current Git (Org mode version 9.5 > (release_9.5-93-gd87250 @ /home/quintus/.emacs.d/org-mode/lisp/)), but > that does not change anything. Either with the NBSP or with a normal > space, the § sign is pulled toward the front. That is, > > Das ist ein Test [cite:@saenger2013gsr § 12 Rn. 488]. > > Still yields: > > § Saenger, Gesellschaftsrecht, 2. Aufl. 2013, 12 Rn. 488 > > Without the NBSP, that is, > > Das ist ein Test [cite:@saenger2013gsr § 12 Rn. 488]. > > it yields: > > § Saenger, Gesellschaftsrecht, 2. Aufl. 2013, 12 Rn. 488 > > Neither is correct; the § should go after the "2013, ". Then, this may be a bug in Citeproc library itself. I suggest to report it upstream. Regards, -- Nicolas Goaziou
Re: org-beamer empty titles
On Sunday, 10 Oct 2021 at 17:44, Joseph Vidal-Rosset wrote: > I reply to my question about org-bullets: the reply is no. Registering > an empty title section delete the space and then the export frame does > not work. :( I am not sure what you mean by "registering". You can type "* " directly to create an empty headline, can you not? In any case, you could try the following maybe: * :sometag: or, if getting desperate, resort to some LaTeX magic: * @@latex:}%@@ -- : Eric S Fraga via Emacs 28.0.60, Org release_9.5-93-gd87250 : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: MathJax extension does not work
Daniel Fleischer writes:
> […] the mathtools.js library was introduced in mathjax 3.2 but org provided
> version 2.7 […]
> You can just change the "path" in 'org-html-mathjax-options'.
I see. I tried the following and it worked:
(with-eval-after-load 'ox-html
(add-to-list 'org-html-mathjax-options
'(path
"https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js;)))
> Secondly, mathtools is not autoloaded so you need to call it; for
> example you can put it in org using "export" block.
>
> #+begin_src HTML
The "export" blocks did not work for me, but the following did:
(setq-default org-html-head "
window.MathJax = {
loader: {load: ['[tex]/mathtools']},
tex: {packages: {'[+]': ['mathtools']}}
};
")
> After that it worked.
> Not sure why the "#+HTML_MATHJAX: mathtools.js" doesn't do anything.
All the above makes using MathJax extensions impractical. I would have to
include HTML hacks in my Org documents or tie the documents to my Emacs
configuration, if I understand everything. Neither sounds right, and thus I
will avoid using "modern" MathJax until Org switches to it and HTML_MATHJAX
actually works.
P.S. I wonder why Org uses MathJax 2.x when other popular tools, such as
Pandoc, use the latest one.
Thank you for your help!
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č
Studenohorská 25
84103 Bratislava
Slovakia
[he/him]
[BUG] Consecutive emphasis markers only work every other time [9.5 (9.5-??-cc2490a70 @ /home/joe/.emacs.d/.local/straight/build-27.1/org/)]
Steps to reproduce:
Enter org mode (I am on cc2490a7061955395c4f5a1a23a088044554a2f7)
Type *bold* *bold* *bold*
Notice that the second instance is not bolded while the first and third
are.
This doesn't occur if there is normal text between the text with
emphasis markers. It shows for all of /italics/, *bold*, _underline_,
and +strikethrough+
Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
of 2020-09-19
Package: Org mode version 9.5 (9.5-??-cc2490a70 @
/home/joe/.emacs.d/.local/straight/build-27.1/org/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-mode-hook '(#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-show-all append local] 5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-babel-show-result-all append local]
5]
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-agenda-loop-over-headlines-in-active-region nil
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-show-empty-lines org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-export-before-parsing-hook '(org-attach-expand-links)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
("id" :follow org-id-open)
("eww" :follow org-eww-open :store org-eww-store-link)
("rmail" :follow org-rmail-open :store org-rmail-store-link)
("mhe" :follow org-mhe-open :store org-mhe-store-link)
("irc" :follow org-irc-visit :store org-irc-store-link :export
org-irc-export)
("info" :follow org-info-open :export org-info-export :store
org-info-store-link)
("gnus" :follow org-gnus-open :store org-gnus-store-link)
("docview" :follow org-docview-open :export org-docview-export
:store org-docview-store-link)
("bibtex" :follow org-bibtex-open :store org-bibtex-store-link)
("bbdb" :follow org-bbdb-open :export org-bbdb-export :complete
org-bbdb-complete-link :store org-bbdb-store-link)
("w3m" :store org-w3m-store-link)
("doi" :follow org-link-doi-open :export org-link-doi-export)
("file+sys") ("file+emacs") ("shell" :follow org-link--open-shell)
("news" :follow
#[514 "\301\300\302Q\"\207" ["news" browse-url ":"] 6
"\n\n(fn URL ARG)"]
)
("mailto" :follow
#[514 "\301\300\302Q\"\207" ["mailto" browse-url ":"] 6
"\n\n(fn URL ARG)"]
)
("https" :follow
#[514 "\301\300\302Q\"\207" ["https" browse-url ":"] 6
"\n\n(fn URL ARG)"]
)
("http" :follow
#[514 "\301\300\302Q\"\207" ["http" browse-url ":"] 6
"\n\n(fn URL ARG)"]
)
("ftp" :follow
#[514 "\301\300\302Q\"\207" ["ftp" browse-url ":"] 6
"\n\n(fn URL ARG)"]
)
("help" :follow org-link--open-help :store org-link--store-help)
("file" :complete org-link-complete-file)
("elisp" :follow org-link--open-elisp))
org-link-elisp-confirm-function 'yes-or-no-p
)
Re: MathJax extension does not work
Daniel Fleischer writes: > Not sure why the "#+HTML_MATHJAX: mathtools.js" doesn't do anything. > Need further investigation. After examining the function 'org-html--build-mathjax-config' in 'ox-html.el' and also looking at the default values of - 'org-html-mathjax-options' - 'org-html-mathjax-template' I don't see any code that loads mathjax extensions; which means the documentation in https://orgmode.org/manual/Math-formatting-in-HTML-export.html is not accurate. That's my understanding. -- Daniel Fleischer
Re: Citations: non-page locators placed in front of citation
Am Sonntag, dem 10. Oktober 2021 schrieb Nicolas Goaziou: > On the contrary, feedback on citations is very much welcome. This is > a new features, and as such, has some rough edges. Thanks for bearing with me. > It is a bug. You use a non-breaking space between the locator and the > number. I hadn't anticipated this (duh!). I fixed it. Could you confirm > it? Actually, I have remapped the § key to automatically always insert an NBSP following it -- I need the § sign all the time and in normal text line-breaking after the § violates typographic rules. Thus I did not notice I had an NSBP there. Apologies for not mentioning this. I however do not think the problem is related to the NBSP. I just retried without it, and the § sign is still pulled towards the front. I also retried with current Git (Org mode version 9.5 (release_9.5-93-gd87250 @ /home/quintus/.emacs.d/org-mode/lisp/)), but that does not change anything. Either with the NBSP or with a normal space, the § sign is pulled toward the front. That is, Das ist ein Test [cite:@saenger2013gsr § 12 Rn. 488]. Still yields: § Saenger, Gesellschaftsrecht, 2. Aufl. 2013, 12 Rn. 488 Without the NBSP, that is, Das ist ein Test [cite:@saenger2013gsr § 12 Rn. 488]. it yields: § Saenger, Gesellschaftsrecht, 2. Aufl. 2013, 12 Rn. 488 Neither is correct; the § should go after the "2013, ". -quintus -- Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite Passau, Deutschland | kont...@guelker.eu| O<
Re: org-beamer empty titles
Le 10/10/2021 à 19:28, Joseph Vidal-Rosset a écrit : > > > Le 10/10/2021 à 19:22, Eric S Fraga a écrit : >> On Sunday, 10 Oct 2021 at 17:12, Joseph Vidal-Rosset wrote: >>> If there is no title following star(s), then the export into frame does >> >> If you mean that you have a headline but with nothing but the *s, what >> happens if you add a space after the last *? I.e. have a not empty >> headline but one that leads to nothing to print? This works for me in >> that the LaTeX compiles and the frame title is empty. > > The problem is that, surprisingly, the space is deleted as soon as the > file is registered. I am using org-bullets, is it the cause of this > problem? I reply to my question about org-bullets: the reply is no. Registering an empty title section delete the space and then the export frame does not work. :(
Re: MathJax extension does not work
Rudolf Adamkovič writes:
> I would like to use the "\mathclap" command from the "mathtools" package in
> my Org document. In LaTeX, it works. For
Hi, there are 2 problems: first the mathtools.js library was introduced in
mathjax 3.2 but org provided version 2.7 as can be seen in the HTML
#+begin_src html
https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.0/MathJax.js?config=TeX-AMS_HTML";>
#+end_src
One can use the newer mathjax by replacing this with
#+begin_src html
https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js";>
#+end_src
as seen in https://docs.mathjax.org/en/latest/web/start.html.
You can just change the "path" in 'org-html-mathjax-options'.
Secondly, mathtools is not autoloaded so you need to call it; for
example you can put it in org using "export" block.
#+begin_src HTML
window.MathJax = {
loader: {load: ['[tex]/mathtools']},
tex: {packages: {'[+]': ['mathtools']}}
};
#+end_src
After that it worked.
Not sure why the "#+HTML_MATHJAX: mathtools.js" doesn't do anything.
Need further investigation.
--
Daniel Fleischer
Re: org-beamer empty titles
Le 10/10/2021 à 19:22, Eric S Fraga a écrit : > On Sunday, 10 Oct 2021 at 17:12, Joseph Vidal-Rosset wrote: >> If there is no title following star(s), then the export into frame does > > If you mean that you have a headline but with nothing but the *s, what > happens if you add a space after the last *? I.e. have a not empty > headline but one that leads to nothing to print? This works for me in > that the LaTeX compiles and the frame title is empty. The problem is that, surprisingly, the space is deleted as soon as the file is registered. I am using org-bullets, is it the cause of this problem? Thanks for your help, Eric. All the best, Jo.
Re: org-beamer empty titles
On Sunday, 10 Oct 2021 at 17:12, Joseph Vidal-Rosset wrote: > If there is no title following star(s), then the export into frame does If you mean that you have a headline but with nothing but the *s, what happens if you add a space after the last *? I.e. have a not empty headline but one that leads to nothing to print? This works for me in that the LaTeX compiles and the frame title is empty. -- : Eric S Fraga via Emacs 28.0.60, Org release_9.5-93-gd87250 : Latest paper written in org: https://arxiv.org/abs/2106.05096
org-beamer empty titles
Hello everybody, With an .org file for presentation: #+TITLE: #+DATE: #+OPTIONS: H:2 toc:nil author:t #+LATEX_CLASS: beamer-fr #+LANGUAGE:fr I meet the following problem: If there is no title following star(s), then the export into frame does not work. This behavior is not convenient: often space is needed in some frame and titles are not necessary. I do not find the solution, hence my email to this list. Best wishes, Jo.
window management for logging and capturing notes
Hello all, TL;DR: Is there something equivalent to org-src-window-setup for log notes and org capture? I cannot find it. Longer: I'm sure org has the capability I want (it always does) but I cannot find it: as screens get bigger, I find I use more windows in a given frame. Looking at the code leads me to believe that what I want is not implemented but just in case... One typical scenario is a zoom/teams window as one of many windows in a frame during an online meeting. I should say I use exwm so Emacs is my window manager and I have a single frame on each monitor. During these meetings, I often want to capture things (org-capture) and/or add notes (org-add-note) to a heading in a document. Unfortunately, I cannot seem to have the type of control I wish over how new windows pop up for these notes and often my meeting video disappears until the note is complete. In general, I would want org-capture and note logging to use the current window. If there is no such setting, I will play around with display-buffer-alist, I guess. Thank you, eric -- : Eric S Fraga via Emacs 28.0.60, Org release_9.5-93-gd87250 : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: 9.5: coping with loss of ditaa.jar
Aloha, Jarmo Hurri writes: Greetings. 2. Use the program "ditaa" (not ditaa.jar) that comes with your operating system. This _may_ work, but I have not been able to misuse the settings in ob-ditaa widely enough yet to create a working solution. This worked for me on Ubuntu 20.04, if it is helpful. sudo apt-get install ditaa Then set org-ditaa-jar-path to "/usr/bin/ditaa". All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: how to export to odt with 11 or 10 pt fonts? Default font setting
Unless you insist on using Computer Modern with a word processing programm (yes, it can be done, at least with the OTF versions of these fonts), or Times New Roman/Cambria with LaTeX (again possible thanks to their OTF incarnation) and slaving to force LaTeX choices on Word (or Word choices on LaTeX, much harder and probably abysmally stupid), your resulting documents will vary for much larger reasons : floats handling, table structures, layout structure, different ligatures, different kernings, etc... Add maths and bibliographic references to the mix, and your chances of obtaining "the same result" are about those of a snowball in Sirius' photosphere... BTW: since most of what is typeset nowadays will be used as PDF, HTML and/or epub (and paper-printed only for archival purposes), it is high time to revisit typography funamentals (currently based on more than 5 centuries of use of the *physics* of the "paper" medium) to adapt them to the physics of computer display and the physiology of human reading of this new medium (which is *not* the same as "paper" reading). This dautingly complex task has not yet attracted the attention of our myriads of "communication specialists", who also carefully shun the problem of retinking what should be the layout of a publication aimed at electronic media and embalm the habits (such as justification, pagination, foot- and end-notes, bibliographic references and entries, indexes, etc...) born of 5 centuries of paper-printed, codex-bound publications... HTH, -- Emmanuel Charpentier
Re: [org-cite] add convention for direct commands, process for adding mappings to export processor(s)?
Just bumping this. Nicolas, in particular, any thoughts? On Thu, Sep 9, 2021 at 2:37 PM Bruce D'Arcus wrote: > > The current list of styles and variants included in the oc export > processors was a first step, with a goal to provide a solid starting > point, and citations that are more-or-less portable across the > backends. > > But that raises an obvious question: what next? > > I'd like, for example, to suggest adding "noauthor/bare" -> "cite*" to > oc-biblatex. > > I also think we should add a way for users to use a direct command for > natbib and biblatex. > > As I've looked into some of what I'd call corner cases, consistency > breaks down a bit, so it may not be advisable to add explicit support > for certain options, since they won't work across different backends > anyway. > > Perhaps some prefix for a style that signals to pass on directly for a > specific export processor; like [cite/blx+footcite ...]. > > In that case, the oc-biblatex processor would pass that command on as > is, but other processors would ignore it, and use the default instead. > > The documentation would just need to emphasize use of such commands > would necessarily tie those citations to the specific export backend. > > And if we were to add this, we'd still need to answer my first > question: when and how to add specific style/variant mappings to the > oc processors. > > Thoughts? > > Bruce
Re: Expanding how the new cite syntax is used to include cross-references - thoughts?
Can we go back to this question of whether internal links are adequate for cross-references, and if not, what's missing? On Fri, Aug 13, 2021 at 11:22 AM Eric S Fraga wrote: > > Hello John & co., > > I need to chime in when it comes to the UI: > > On Thursday, 12 Aug 2021 at 13:19, John Kitchin wrote: > > I would say the UI that I like, have used for many years, and is the > > default of org-ref is: > > > > 1. You type C-c ] to insert a citation > > 2. You type C-u C-c ] to insert a cross-reference > > 3. you type C-u C-u C-c ] to insert a new label. > > UI is a very personal thing. So long as there are 3 different functions > that implement these actions, I would be happy... [snip] > In terms of the bigger picture, citations and cross-references, to me, > are different things (one is external and the other usually internal, > respectively) and I see no benefit in conflating them. I am also still > not convinced that org links are not sufficient ... In reviewing and playing with this functionality a bit, it's clear to me that internal links are intended to be cross-references, even if they fall short for certain classes of users. Let's take a simple example of a figure, adapted from the manual: #+begin_example #+CAPTION: This is the caption. #+NAME: fig:SED-HR4049 [[./img/a.jpg]] Here's a cross-reference to Figure [[fig:SED-HR4049]]. #+end_example This internal link seems to produce consistent and correct output across latex, html, and odt. The "fig" prefix is meaningful to ref in latex to enable it to type that cross-reference. I'm unsure how typing in the odt context works, but it does. The only downside is one has to manually, per the example, insert the prefix (here "Figure ") in text (though this is a small price to pay in my view). If one wants to use cleveref or autoref instead, as is now possible with a recent commit, those packages handle that automatically. But of course, this only works in latex, so you lose the consistency across the backends. Also, you then need to be able to specify different variants locally (for example, cref vs Cref), which is not possible currently. So I'm unclear: is that added functionality and complexity really needed? Is there something else I'm missing? A separate, possibly more important (?), matter is UI and supporting functionality. I think it would be nice to have better UI support for inserting these references. To John's point, could we add interactive functions to insert labels and cross-references (say as customizable functions?), using the existing internal link support, and iterate that support over time? Bruce
Re: [org-cite] allow citations in captions?
On Sun, Oct 10, 2021 at 8:00 AM Nicolas Goaziou wrote: > > Hello, > > "Bruce D'Arcus" writes: > > > Is there any technical reason citations aren't allowed in captions? > > Yes, there is. Captions are somewhat fragile: they may or may not be > included in the final output. So this might introduce some subtle bugs, > such as pointers (op. cit., or ibid) to non-existing references. For the > same reason, footnotes references are not allowed in citations either. > I don't know if the benefits outweigh these possible complications. I'm not sure either. But they're not uncommon in the wild. The "subtle bugs" you mention: does that example you note only apply to output formats that omit the captions? The important export formats for academic writing are latex, odt, and (less so) html, all of which do include the captions. Are there others you are thinking of? Bruce
Re: [ANN] New `bibtex' citation processor
Tried it out just now and it works very well! Thank you. -- : Eric S Fraga via Emacs 28.0.60, Org release_9.5-93-gd87250 : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: [ANN] New `bibtex' citation processor
Thank you Nicolas! This should fit my usual work practices quite nicely. -- : Eric S Fraga via Emacs 28.0.60, Org release_9.5-63-g67b613 : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: [org-cite] allow citations in captions?
Hello, "Bruce D'Arcus" writes: > Is there any technical reason citations aren't allowed in captions? Yes, there is. Captions are somewhat fragile: they may or may not be included in the final output. So this might introduce some subtle bugs, such as pointers (op. cit., or ibid) to non-existing references. For the same reason, footnotes references are not allowed in citations either. I don't know if the benefits outweigh these possible complications. Regards, -- Nicolas Goaziou
[org-cite] allow citations in captions?
Is there any technical reason citations aren't allowed in captions?
If not, could that restriction be removed?
I do note LaTeX requires special handling for that though;
\protect\cite{ref} or {\cite{ref}}.
https://stackoverflow.com/questions/4487728/latex-inserting-a-reference-in-a-figures-caption
Bruce
Re: Citations: non-page locators placed in front of citation
Hello,
M. ‘quintus’ Gülker writes:
> apologies for my frequent e-mails. It’s just that I am evaluating the
> citations facility for me.
On the contrary, feedback on citations is very much welcome. This is
a new features, and as such, has some rough edges.
> This time it’s about non-page locators. Take the following document:
>
> #+TITLE: Test
> #+AUTHOR: testauthor
>
> #+LANGUAGE: de
> #+bibliography: /tmp/mwe/mwe.bib
>
> #+cite_export: csl /tmp/mwe/juristische-schulung.csl
>
> Das ist ein Test [cite:@saenger2013gsr § 12 Rn. 488].
>
> juristische-schulung.csl is
> https://github.com/citation-style-language/styles/blob/e22b8a566bad9b4c7f52720f60dd875057a5d210/juristische-schulung.csl.
>
> This is mwe.bib:
>
> @Book{saenger2013gsr,
> author = {Ingo Saenger},
> title= {Gesellschaftsrecht},
> year = {2013},
> edition = {2},
> publisher = {Franz Vahlen},
> location = {München},
> langid= {ngerman}}
>
> Note how this work is not cited by page, but instead (which is common
> among German judicial literature) by section number (§) plus margin number
> (Rn.). Exporting this e.g. to HTML yields in Footnote 1:
>
> § Saenger, Gesellschaftsrecht, 2. Aufl. (2013), 12 Rn. 488
>
> That is rather unexpected. It has pulled the § sign in front of the
> citation. The citation should have looked like this:
>
> Saenger, Gesellschaftsrecht, 2. Aufl. (2013), § 12 Rn. 488
[...]
> Is it a bug or (again) my error?
It is a bug. You use a non-breaking space between the locator and the
number. I hadn't anticipated this (duh!). I fixed it. Could you confirm
it?
Thank you.
Regards,
--
Nicolas Goaziou
MathJax extension does not work
I would like to use the "\mathclap" command from the "mathtools" package in my
Org document. In LaTeX, it works. For HTML, I visited the Org manual [1] where
I saw the following example:
#+HTML_MATHJAX: cancel.js noErrors.js
with a comment "it loads the two MathJax extensions ‘cancel.js’ and
‘noErrors.js’ [132]." (As a side-note, the first link in [132] points to 404.)
Thus, I put the following into my Org file
#+HTML_MATHJAX: mathtools.js
but it seems to do nothing; the exported HTML code not even contain the word
"mathtools".
A file that demonstrates the problem:
#+LATEX_HEADER: \usepackage{mathtools}
#+HTML_MATHJAX: mathtools.js
\begin{equation*}
\begin{aligned}
\lim_{R\to0}F_1
=\lim_{R\to0}\frac{2PR}{P+R}
=\lim_{R\to0}\frac{2\cdot0\cdot{}R}{0+R}
=\lim_{R\to0}\frac{0}{R},
=\underbrace{\lim_{R\to0}\frac{0}{1}}_{\mathclap{\text{by L'Hôpital's Rule with
$\frac{d}{dR}R=1$}}}
=\lim_{R\to0}0
=0.
\end{aligned}
\end{equation*}
Rudy
[1] https://orgmode.org/manual/Math-formatting-in-HTML-export.html
--
"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č
Studenohorská 25
84103 Bratislava
Slovakia
[he/him]
Re: 9.5: coping with loss of ditaa.jar
Another alternative which I just found is the ditaa version on github, which has SVG support. See https://github.com/stathissideris/ditaa. If you click on the 'release' link on the right, there is the most recent release, which includes a link to a standalone ditaa.jar file. I've not tried this version, but suspect it will work fine (assuming they use semantic versioning, which indicates the API has not changed).
Citations: non-page locators placed in front of citation
Dear all,
apologies for my frequent e-mails. It’s just that I am evaluating the
citations facility for me.
This time it’s about non-page locators. Take the following document:
#+TITLE: Test
#+AUTHOR: testauthor
#+LANGUAGE: de
#+bibliography: /tmp/mwe/mwe.bib
#+cite_export: csl /tmp/mwe/juristische-schulung.csl
Das ist ein Test [cite:@saenger2013gsr § 12 Rn. 488].
juristische-schulung.csl is
https://github.com/citation-style-language/styles/blob/e22b8a566bad9b4c7f52720f60dd875057a5d210/juristische-schulung.csl.
This is mwe.bib:
@Book{saenger2013gsr,
author = {Ingo Saenger},
title= {Gesellschaftsrecht},
year = {2013},
edition = {2},
publisher = {Franz Vahlen},
location = {München},
langid= {ngerman}}
Note how this work is not cited by page, but instead (which is common
among German judicial literature) by section number (§) plus margin number
(Rn.). Exporting this e.g. to HTML yields in Footnote 1:
§ Saenger, Gesellschaftsrecht, 2. Aufl. (2013), 12 Rn. 488
That is rather unexpected. It has pulled the § sign in front of the
citation. The citation should have looked like this:
Saenger, Gesellschaftsrecht, 2. Aufl. (2013), § 12 Rn. 488
If I replace the citation in the document with
Das ist ein Test [cite:@saenger2013gsr p. 245].
then it produces the expected
Saenger, Gesellschaftsrecht, 2. Aufl. (2013), 245
(the page locator label, "S." in German, is intentionally suppressed by
the CSL style, so this is not a bug. However, the § locator has to
appear and is not suppressed by the CSL style).
If I export with the default "bare" processor, the citation comes out
fine as "(Ingo Saenger, 2013 § 12 Rn. 488)".
I conclude from this that org somehow mistreats the locator if it is not
a page number. I used org 9.5 from MELPA and Citeproc.el from commit
34e66583d95a8d80fb5b9f2960f3382ca0e6d3ab.
Is it a bug or (again) my error?
-quintus
--
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland | kont...@guelker.eu| O<
Re: 9.5: coping with loss of ditaa.jar
Jarmo Hurri writes: > Greetings. > > Let me collect the suggested responses with their merits and potential > issues. > > 1. Use ditaa.jar that comes with your operating system. Perfect if this >works. Seems to work e.g. in Debian, does not seem to work with >Fedora. Perhaps because one is a standalone library and the other one >is not. Could also be a version number issue. > > 2. Use the program "ditaa" (not ditaa.jar) that comes with your >operating system. This _may_ work, but I have not been able to misuse >the settings in ob-ditaa widely enough yet to create a working >solution. > > 3. Copy ditaa.jar from previous version of org. Works in the short run, >but I do not think we want to advocate this: "We took ditaa.jar out >of org, so you will want to download an earlier version of org to >make ditaa work." > > 4. Use precompiled binary ditaa.jar from some site. Will probably work, >but me and some other paranoids try to avoid using binaries from >sources which we do not consider reliable. > > 5. Compile ditaa.jar yourself. At least for me, does not work at the >moment. > I think you missed one obvious solution - donwload the jar file from the ditaa project homepage on sourceforge. This is what I did some years ago (there has not been an update to ditaa since 2013) and I placed the jar file in a lib folder on my system (completely separate from org, emacs etc) and then just set the path in my init file. This has been in place for me for at least 5 years (since I setup this computer) and has not needed to be changed through many updates/upgrades of both org and emacs. I don't think you need to be paranoid about downloading the jar file from the project homepage - either you trust the code or you don't. If you don't trust the code, then even compiling it yourself adds no additonal protection.
