Re: MathJax extension does not work

[chris]

On Sunday, 10 October 2021 11:14:24 CEST Rudolf Adamkovič wrote:
> 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
> 

With similar scenario I ended up with:
(and `mathjax` extensions work very well)

```org-mode
#+STARTUP: latexpreview

#+BEGIN_EXPORT html

window.MathJax = {
  loader: {
paths: {unicodeMath:

'https://cdn.jsdelivr.net/npm/@amermathsoc/mathjax-unicode-math@1/browser'},
load: ['[tex]/mathtools', '[unicodeMath]/unicode-math.js']},
tex: {packages: {'[+]': ['mathtools', 'unicode-math']}}};

#+END_EXPORT

\begin{array}{ccc}
  \underset{\longrightarrow}{\lim}^f(\alpha_1 \circ p_1)
  &\overset{\underset{\longrightarrow}{\lim}^f \phi}{\longrightarrow}&
  \underset{\longrightarrow}{\lim}^f(\alpha_2 \circ p_2)
  \\
{}^{\mathllap{\simeq}}\downarrow
&&
\downarrow^{\mathrlap{\simeq}}
\\
\underset{\longrightarrow}{\lim}^f \alpha_1
&\underset{f}{\longrightarrow}&
\underset{\longrightarrow}{\lim}^f \alpha_2
\end{array}

(diagram above from: [[https://ncatlab.org/nlab/show/ind-object][ind-object in 
nLab]])

\(\Bbbc\)

This above uses the other extension, unicode-math.
```

It works when exporting to `latex` and then `pdf`,
it works very well when exporting to `html` via `org-html-export-to-html`,
it almost works with `org-latex-preview`.

Here the relevant part of my `config.org`:

```org-mode
#+begin_src emacs-lisp
  (with-eval-after-load 'org
  (add-to-list 'org-latex-packages-alist '("" "stmaryrd" t))
  (add-to-list 'org-latex-packages-alist '("" "tikz-cd" t))
  (add-to-list 'org-latex-packages-alist '("" "amscd" t))
  (add-to-list 'org-latex-packages-alist '("" "mathtools" t))
  (add-to-list 'org-latex-packages-alist '("" "unicode-math" t))
  ;; (add-to-list 'org-latex-packages-alist '("" "breqn" t))
  (add-to-list 'org-latex-packages-alist '("" "thisisastupidtestfile" t))
  (setq org-latex-create-formula-image-program 'dvisvgm)
  (setq org-format-latex-options
(plist-put org-format-latex-options :scale 0.80)))
#+end_src
```

`thisisastupidtestfile.sty` contains a few straightforward macro of the sort of 
`\newcommand{\calT}{\mathcal{T}}`.

Everything works save `unicode-math` which doesn't work with anything `dvi`.

I use `dvisvgm` because it allows `tikz` to work with `org-latex-preview`.

Cheers,
Chris


> 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
> 
> 

Re: [PATCH] Async evaluation in ob-shell

[Matt]

  On Fri, 24 Mar 2023 05:13:34 -0400  Ihor Radchenko  wrote --- 

 > A small note on the WORG page: it may be more natural to use :async yes
 > rather than :async t. Both are viable - in fact, anything other than
 > :async no and :async none will be treated as "t".
 
Ah, okay.  I'll make that more clear.

Somewhat related, I had this left over from when I was working out the async 
code.  It prevents the user from running :async without the (required) :session 
header.The :async header runs the default (blocking) process when :session 
is missing.

diff --git a/lisp/ob-comint.el b/lisp/ob-comint.el
index 86c2bf7a7..384bfcda8 100644
--- a/lisp/ob-comint.el
+++ b/lisp/ob-comint.el
@@ -206,11 +206,12 @@ comint outputs due to buffering.")
 PARAMS are the header arguments as passed to
 `org-babel-execute:lang'."
   (let ((async (assq :async params))
-(session (assq :session params)))
+(sessionp (not (member (cdr (assq :session params)) '("no" "none")
+(if (and async (not sessionp))
+  (error (org-babel-eval-error-notify 1 "ERROR: must use 'async' with 
'session'")))
 (and async
-(not org-babel-exp-reference-buffer)
- (not (equal (cdr async) "no"))
- (not (equal (cdr session) "none")
+ sessionp
+ (not org-babel-exp-reference-buffer
 
 (defun org-babel-comint-async-filter (string)
   "Captures Babel async output from comint buffer back to Org mode buffers.

It's really just a nicety.  The user can cancel the accidental blocking process 
with C-g.  However, the block is run in a different shell than expected and 
it's jarring to have Emacs freeze when you expect async.

Thoughts on including it or something similar?

error-on-async-session-mismatch.diff
Description: Binary data

Re: Remove "shell" as a supported Babel language within ob-shell.el (was Re: [SUGGESTION] ob-shell async result output should not contains shell prompt)

[Matt]

  On Fri, 24 Mar 2023 07:38:58 -0400  Ihor Radchenko  wrote --- 

  > I suggest the following:
 > 1. Introduce a new customization `org-babel-default-shell', defaulting
 >to (or (executable-find "sh") (executable-find "cmd.exe")).
 > 2. Use the value as default shell in "shell" code blocks.
 > 3. Document and announce the change.
 > 4. Create org-lint checker that will mark "shell" code blocks as not
 >desired.
 > 
 > The above steps will ensure minimal breakage for existing uses of
 > "shell" blocks. Only users who wrote shell blocks for non-standard shell
 > will have to adapt.
 
These are good suggestions.  Thank you!

Re: [FR] Do not resolve relative "file" paths

[Samuel Wales]

might or might not help also that the default value appers to use
substitute-in-file-name behind the scenes.

On 3/27/23, Ruijie Yu via General discussions about Org-mode.
 wrote:
>
> Ihor Radchenko  writes:
>
>> [...]
>> You can customize `org-link-file-path-type'.
>
> Thank you, this is exactly what I needed.  It is even able to convert my
> previous absolute paths back to relative paths, which is great.
>
> --
> Best,
>
>
> RY
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading? (was: org-ctags land grab)

[Dr. Arne Babenhauserheide]

Ihor Radchenko  writes:

> Max Nikulin  writes:
>
>>> Sure. This is not by itself a big deal. A number of Elisp libraries,
>>> including built-in Emacs libraries are loaded with side effects.
>>
>> It is still violation of conventions:
>>
>> (info "(elisp) Coding Conventions")
>> https://www.gnu.org/software/emacs/manual/html_node/elisp/Coding-Conventions.html
>>> D.1 Emacs Lisp Coding Conventions
>>> 
>>> Simply loading a package should not change Emacs’s editing behavior.
>>> Include a command or commands to enable and disable the feature, or to
>>> invoke it.
>>> 
>>> This convention is mandatory for any file that includes custom
>>> definitions. If fixing such a file to follow this convention requires an
>>> incompatible change, go ahead and make the incompatible change; don’t
>>> postpone it.
>
> This is convincing.
> I am then CCing Bastien, as, despite the Elisp convention, following it
> will break https://bzg.fr/en/the-software-maintainers-pledge/

Isn’t the problem that the behavior changed — so that org-ctags gets
loaded in Emacs 30 but not in Emacs 28 is already an incompatible
change?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Max Nikulin]

On 26/03/2023 00:45, Ihor Radchenko wrote:

I am then CCing Bastien, as, despite the Elisp convention, following it
will break https://bzg.fr/en/the-software-maintainers-pledge/


I hope, it may be mitigated to some degree, e.g. loading of 
`org-modules' and `org-babel-load-languages' may include their 
activation. Perhaps `org-require-package' should activate the loaded 
package as well.


If it is possible to avoid user prompt in org-ctags then migration may 
be done in 2 steps separated by a year: add new require helper and do 
not activate by default. Unsure if it is possible to add some warnings 
on first step that activate function is not called.



(defun enable-feature (feature  filename noerror)
   "Load and enable FEATURE.
FILENAME and NOERROR arguments are the same as in `require'."
   (when (require feature filename noerror)
 (let ((enabler-cmd (intern (format "%s-enable-function" feature
   (and (fboundp enabler-cmd) (funcall enabler-cmd)


I would prefer activating on first call only, subsequent calls should be 
no op.



(defun disable-feature (feature)


I had a hope that existing `unload-feature' is enough.

My idea was something like `org-require' that is (require feature) and 
(feature-activate) or (feature-activate-function) *once*.

Re: [FR] Do not resolve relative "file" paths

[General discussions about Org-mode.]

Ihor Radchenko  writes:

> [...]
> You can customize `org-link-file-path-type'.

Thank you, this is exactly what I needed.  It is even able to convert my
previous absolute paths back to relative paths, which is great.

--
Best,


RY

Re: [FR] Do not resolve relative "file" paths

[Ihor Radchenko]

[FR] Do not resolve relative "file" paths

Canceled.

Re: [FR] Do not resolve relative "file" paths

[Ihor Radchenko]

Ruijie Yu via "General discussions about Org-mode."
 writes:

> C-c C-l file:../4 RET RET
> [[file:/tmp/tmp.ztrbRDDtKy/4]]
> C-c C-l file:../2 RET RET
> [[file:/tmp/tmp.ztrbRDDtKy/2]]
> --8<---cut here---end--->8---
>
> Note that I showcased both ../4 and ../2 because it seems that the
> referenced file does not need to exist.
>
> I expect the links to be literally [[file:../4]] and [[file:../2]]
> respectively.  This is helpful for me to reference other files
> relatively (e.g., in a repository).

You can customize `org-link-file-path-type'.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

[FR] Do not resolve relative "file" paths

[General discussions about Org-mode.]

Both Emacs and Org are on recent master commits.

Repro:

--8<---cut here---start->8---
$ cd $(mktemp -d)
$ mkdir 1
$ touch 2
$ emacs -L /org/lisp/ -Q 1/3.org
M-: emacs-repository-version RET
"db7e95531ac36ae842787b6c5f2859d0642c78cc"
M-x org-version RET
Org mode version 9.7-pre (release_9.6.1-321-g44e1cb @ 
/opt/src/emacs/packages/orgmode/main/lisp/)
C-c C-l file:../4 RET RET
[[file:/tmp/tmp.ztrbRDDtKy/4]]
C-c C-l file:../2 RET RET
[[file:/tmp/tmp.ztrbRDDtKy/2]]
--8<---cut here---end--->8---

Note that I showcased both ../4 and ../2 because it seems that the
referenced file does not need to exist.

I expect the links to be literally [[file:../4]] and [[file:../2]]
respectively.  This is helpful for me to reference other files
relatively (e.g., in a repository).

For example, since I am working on translating orgweb to zh_CN, I have
/zh_CN/index.org referencing /resources/img/xyz.svg, where after I do
`C-c C-l file:../resources/img/xyz.svg RET' inside /zh_CN/index.org, Org
resolves this link to an absolute path which is counterproductive and
does not work beyond my own computer.

--
Best,


RY

Re: Friendly exchange of thoughts: citations and LaTeX

[Pedro Andres Aranda Gutierrez]

> And often a source of real issues (I
> have this problem sharing with my group where most use Windows... issues
> with paths and upper/lower case names).

I don't know why, but it sounds familiar ;-)

Best, /PA

On Mon, 27 Mar 2023 at 11:34, Fraga, Eric  wrote:
>
> Hi Pedro,
>
> On Monday, 27 Mar 2023 at 11:02, Pedro Andres Aranda Gutierrez wrote:
> > \jobname is the shorthand for ‘the file that you are compiling with
>
> Ah, okay; thank you.
>
> > Re the use of absolute vs relative path when exporting to LaTeX, I
> > might want to export to LaTeX and transfer to overleaf.com and
> > relative paths would make more sense there, wouldn’t they?
>
> Yes, this is a very valid point.  And often a source of real issues (I
> have this problem sharing with my group where most use Windows... issues
> with paths and upper/lower case names).
>
> --
> : Eric S Fraga, with org release_9.6.1-307-gcd2355 in Emacs 30.0.50



-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
run a leader-deposed hook here, but we can't yet

Re: [BUG] No space after footnote with org-export-with-footnotes set to nil [9.6.1 ( @ /Users/test/.emacs.d/elpa/28.0/develop/org-9.6.1/)]

[Ihor Radchenko]

Ihor Radchenko  writes:

> Max Nikulin  writes:
>
>>>[previous object ]
>>
>> Yes, you do.
>>
>> I expected some complications due to newline characters (not line break 
>> markup objects), but they are not included in :post-blank and 
>> represented as "\n" string objects.
>
> Newlines are tricky. They may or may not be significant.
> For example, in CJK paragraphs, newlines are to be stripped.
>
> I think that a reasonable thing to do could be not adding newlines if
> the previous object is a plain string ending with a newline.

I think that using max(n1,n2) is an overkill. There is no reason to
alter existing spaces before, if any.

I am attaching tentative patch that simply keeps spaces, but if and only
if the previous object does not end with whitespace (including newline).

>From 656c32d075d939aa69bc315bc91515930680377c Mon Sep 17 00:00:00 2001
Message-Id: <656c32d075d939aa69bc315bc91515930680377c.1679926405.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Mon, 27 Mar 2023 16:11:32 +0200
Subject: [PATCH] org-export--prune-tree: Ensure spaces when removing objects

* lisp/ox.el (org-export--prune-tree): If the removed object has
trailing spaces and previous object does not have, keep the trailing
spaces.
* etc/ORG-NEWS (Blank lines after removed objects are not retained
during export): Document the change.

Reported-by: Andrea Lazzarini 
Link: https://orgmode.org/list/87o7p7z9k3.fsf@localhost
---
 etc/ORG-NEWS | 21 +
 lisp/ox.el   | 19 ++-
 2 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index ac233a986..caf140279 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -145,6 +145,27 @@ execution completes.  The new ~:async~ header allows users to continue
 editing with Emacs while a ~:session~ block executes.
 
 ** Miscellaneous
+*** Blank lines after removed objects are not retained during export
+
+When certain objects in Org document are to be excluded from export,
+spaces after these objects were previously removed as well.
+
+For example, if ~org-export-with-footnotes~ is set to nil, the footnote in 
+
+: Pellentesque dapibus suscipit ligula.[fn:1]  Donec posuere augue in quam.
+
+would be removed, leading to the following exported ASCII document
+
+: Pellentesque dapibus suscipit ligula.Donec posuere augue in quam.
+
+This is because spaces after footnote (and other markup) are
+considered a part of the preceding AST object in Org.
+
+Now, unless there is a whitespace before an object to be removed,
+spaces are preserved during export:
+
+: Pellentesque dapibus suscipit ligula.  Donec posuere augue in quam.
+
 *** Remove undocumented ~:target~ header parameter in ~ob-clojure~
 
 The ~:target~ header was only used internally to distinguish
diff --git a/lisp/ox.el b/lisp/ox.el
index f9fc9a99b..206f0536d 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -2752,7 +2752,24 @@ (defun org-export--prune-tree (data info)
 		(let ((type (org-element-type data)))
 		  (if (org-export--skip-p data info selected excluded)
 		  (if (memq type '(table-cell table-row)) (push data ignore)
-			(org-element-extract-element data))
+			(let ((post-blank (org-element-property :post-blank data)))
+			  (if (or (not post-blank) (zerop post-blank)
+  (eq 'element (org-element-class data)))
+			  (org-element-extract-element data)
+			;; Keep spaces in place of removed
+			;; element, if necessary.
+			;; Example: "Foo.[10%] Bar" would become
+			;; "Foo.Bar" if we do not keep spaces.
+			(let ((previous (org-export-get-previous-element data info)))
+			  (if (or (not previous)
+  (pcase (org-element-type previous)
+	(`plain-text
+	 (string-match-p
+	  (rx  whitespace eos) previous))
+	(_ (org-element-property :post-blank previous
+  ;; Previous object ends with whitespace already.
+  (org-element-extract-element data)
+(org-element-set-element data (make-string post-blank ?\s)))
 		(if (and (eq type 'headline)
 			 (eq (plist-get info :with-archived-trees)
  'headline)
-- 
2.39.1


-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [RFC] ox-icalendar: Unscheduled tasks & repeating tasks

[Ihor Radchenko]

Jack Kamm  writes:

> For patch 1 (unscheduled tasks):
>
> Currently, ox-icalendar does not allow creating an iCalendar task
> without a scheduled start date. If an Org TODO is missing a SCHEDULED
> timestamp, then ox-icalendar sets today as the scheduled start date for
> the exported task.
>
> Patch 1 changes this by adding a new customization
> org-icalendar-todo-force-scheduling. When non-nil, the start date is set
> to today (same as the current behavior). When nil, unscheduled Org TODOs
> are instead exported without a start date.
>
> I also propose the default value to be nil. Note, this is
> backwards-incompatible with the previous behavior!
>
> But I think it should be the default anyways, because IMO it is the more
> correct and useful behavior. An iCalendar VTODO without a DTSTART
> property is valid, and has the same meaning as an Org TODO without a
> SCHEDULED timestamp. Also, all the iCalendar programs I have tried
> support unscheduled tasks, including Thunderbird, Evolution, Nextcloud,
> and Tasks.org.

I agree that omitting DTSTART will make more sense.

> For patch 2 (repeating timestamps):
>
> I add recurrence rule (RRULE) export for repeating SCHEDULED and
> DEADLINE timestamps in TODOs, similar to how repeating non-TODO events
> are currently handled.
>
> The main complication here is that iCalendar's RRULE applies to both
> DTSTART and DUE properties; by contrast, Org's SCHEDULED and DEADLINE
> timestamps may have different repeaters. I am not sure the best way to
> handle the case where SCHEDULED and DEADLINE have different repeaters,
> so in that case I issue a warning and skip the repeater.

In the case of different repeaters, we can use RDATE
(https://icalendar.org/iCalendar-RFC-5545/3-8-5-2-recurrence-date-times.html)
and generate occurrences manually sufficiently far into future. ("how
far" should be a defcustom).

However, different repeaters for deadline and schedule are most likely a
mistake - we can report it via org-lint and in ox-icalendar, as warning.

Another scenario we may need to consider is when schedule has a repeater
while deadline does not, and vice versa. The former scenario is probably
valid - a VTODO with limited number of occurrences. The latter is likely
a mistake we should raise warning about. It is also not clear how to
represent moving event deadline in iCalendar.

See more inline comments below.

> +(defcustom org-icalendar-todo-force-scheduling nil
> +  "Non-nil means unscheduled tasks are exported as scheduled.
> +The current date is used as the scheduled time for such tasks."
> +  :group 'org-export-icalendar
> +  :type 'boolean)

Please add :package-version and possibly :safe keywords.
We may also refer to `org-icalendar-include-todo' in the docstring.

> -  (org-icalendar-convert-timestamp start "DTSTART" nil timezone) "\n"
> + (when start
> +   (concat (org-icalendar-convert-timestamp
> +start "DTSTART" nil timezone)
> +   "\n"))

Side note: here, and in other places, we use "\n" as end of line. Yet,
for example
https://icalendar.org/iCalendar-RFC-5545/3-8-2-4-date-time-start.html
prescribes CRLF (\r\n). Also, see
https://orgmode.org/list/87ilgljv6i.fsf@localhost
If you are familiar with iCalendar spec, may you look through the
ox-icalendar code and check other places where we do not conform to the
newline spec?

Ideally, we want a set of private functions ensuring proper prescribed
format for all the used iCalendar syntax entries. Otherwise, we will
keep forgetting about these subtleties.

> +(defun org-icalendar--rrule (unit value)
> +  (format "RRULE:FREQ=%s;INTERVAL=%d\n"

\r\n

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Table not expanded as I expect upon

[Ihor Radchenko]

alain.coch...@unistra.fr writes:

> Maybe it is normal, but if I put the cursor anywhere in the 1st line
> (say) of this table
>
> ||---+---|
> || x | x |
>
> and press , it becomes
>
> |   | ---+--- |   |
> |   | x   | x |
>
> which is not what I would expect.

This is expected.
Only |- at the beginning of the line is seen by Org as horizontal rule.
||-... is an empty cell || followed by a cell |-...|.

See 3.1 Built-in Table Editor section of Org manual.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Docstring fixes

[Ihor Radchenko]

"Stephen J. Eglen"  writes:

> and a commit message.

Thanks!
Applied, onto bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=fcd813c40

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Document org-hide-emphasis-markers

[Ihor Radchenko]

"Stephen J. Eglen"  writes:

> sure, sorry I missed that.  I have signed papers with FSF for all my
> Emacs contribs.

Thanks!
Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=1e38519b0

I presume that you previously used another email
(s.j.eg...@damtp.cam.ac.uk) for contributions.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Friendly exchange of thoughts: citations and LaTeX

[Fraga, Eric]

Hi Pedro,

On Monday, 27 Mar 2023 at 11:02, Pedro Andres Aranda Gutierrez wrote:
> \jobname is the shorthand for ‘the file that you are compiling with

Ah, okay; thank you.  

> Re the use of absolute vs relative path when exporting to LaTeX, I
> might want to export to LaTeX and transfer to overleaf.com and
> relative paths would make more sense there, wouldn’t they?

Yes, this is a very valid point.  And often a source of real issues (I
have this problem sharing with my group where most use Windows... issues
with paths and upper/lower case names).

-- 
: Eric S Fraga, with org release_9.6.1-307-gcd2355 in Emacs 30.0.50

Re: Friendly exchange of thoughts: citations and LaTeX

[Pedro Andres Aranda Gutierrez]

Hi Eric,

\jobname is the shorthand for ‘the file that you are compiling with the latex 
command’. I use it in my templates for LaTEX presentations and documents I 
conjunction with \addbibresource{} 
I always have a main.Tex + main.bib file pair.

Recognizing this in org-cite would be nice.

Re the use of absolute vs relative path when exporting to LaTeX, I might want 
to export to LaTeX and transfer to overleaf.com and relative paths would make 
more sense there, wouldn’t they?

Thanks for the exchange/PA

Enviado desde mi iPhone

> El 23 mar 2023, a las 11:09, Fraga, Eric  escribió:
> 
> Pedro,
> 
> maybe start by showing an example of where \jobname does not work with
> org while working with LaTeX directly?  I have never used this LaTeX
> command and know nothing about it.
> 
> Secondly, what is the problem with bibliography file names being
> expanded?
> 
> eric
> -- 
> : Eric S Fraga, with org release_9.6.1-224-g8ae8a8 in Emacs 30.0.50