Re: keeping subtree heading on export

[Matt Price]

thanks for the response, Ihor -- reply inline below:

On Fri, Apr 26, 2024 at 9:45 AM Ihor Radchenko  wrote:

> Matt Price  writes:
>
> > ... I need to export each individual page
> > of the "book" to its own markdown page.  However, jupyter-book expects to
> > find the title of the page in the initial first-level heading.  So I'd
> like
> > to retain the subtree "title" as a first-level heading, and demote the
> > remaining headings to their original state within the larger org
> document.
> >
> > Does anyone know of an existing exporter that already does this, from
> which
> > I can steal? Or if not, how would you suggest I go about doing this?
>
> May you provide an example demonstrating initial Org mode document and
> how the exported md documents should look like?
>
>
I don't think my request was very clear.  Let's say I'm writing a "book"
(really a documentation set of some kind) with several "chapters" (really,
each chapter is an indiviual html page, though more complex nesting is
permitted by jupyter-book).

I write in org-mode:

-
* Chapter 1
text
** Chapter 1.1
text
** Chapter 1.2
* Chapter 2
text
** Chapter 2.1
text
-

And I want to produce two markdown files:

chapter-1.md:
-
# Chapter 1
text
##  Chapter 1.1
text
##  Chapter 1.2
--

chapter-2.md

# Chapter 2
text
## Chapter 2.1
text
-

I tried to learn a little more on my own after posting.  I can set
`org-md-toplevel-hlevel` to `2`, and then in the template function add the
title property "manually" by extracting it from the info communication
channel:

--
(defun org-myst-inner-template (contents info)
  "Return body of document after converting it to Markdown syntax.
CONTENTS is the transcoded contents string.  INFO is a plist
holding export options."
  (let* ((depth (plist-get info :with-toc))
 (headlines (and depth (org-export-collect-headlines info depth)))
 (toc-string (or (mapconcat (lambda (headline)
  (org-myst-format-toc headline info))
headlines "\n")
 ""))
 (toc-tail (if headlines "\n\n" ""))
 (front-matter (org-myst-front-matter))
 (title (org-export-data (plist-get info :title) info)))
(org-trim (concat front-matter toc-string toc-tail "\n" "# " title
"\n\n"  contents (org-myst-footnote-section info)
--

This works ok!  But the problem ocmes because I would like to be able to
*also* sometimes export a whole file (rather than just a subtree) using the
same exporter.That's because I have inherited osme projects where files
take hte form:

chapter-1.org
--
* Chapter 1
text
** Chapter 1.1
text
** Chapter 1.2
--
etc.

The real problem I have is that, when exporting a subtree, I want to set
org-md-toplevel-hlevel to "2" and add the title; when exporting a whole
file, I want to set org-md-toplevel-hlevel to "1" and ignore the title.

I don't think this is how org exporters are supposed to work, but I'm
trying to interface to an established system that has chosen osme
un-org-like conventions.

Is this clearer, and do you see a way to do this?  I am just looking at the
source code and I wonder if I could add some (let) bindings inside
org-myst-export-to-markdown and -as-markdown before calling
org-export-to-[buffer|file].

hmm. Just tried it and it seems to work.  Something seems wrong about this
kind of code, though, in which I let-bind a variable in one function solely
so that I can use it in another.  Is there a better way?



 Un that case ,I would want to set


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

help: org-mode menu presence mysteriously disappearing and reappearing when I navigate the document

[Cook, Malcolm]

Hiya org-mode-philes,

I have a org document that, when I navigate through it, the org-mode menu 
disappears and reappears.

I am having trouble debugging this or creating a reproducible example and 
welcome any suggestions as to how to do either, or insight into what might be 
going on.

I do use a variety of org-mode extensions and other packages and when I limit 
my init.el to just basic org mode, the problem goes away, so it is obviously 
some interaction.  They include:

org-table-comment
org-special-block-extras 
org-tidy
org-modern
outshine
polymode
and friends...

Thanks for any insights!

~ Malcolm 

Re: FAILED test-ob-shell/bash-uses-assoc-arrays

[Max Nikulin]

On 26/04/2024 18:08, Ihor Radchenko wrote:

Max Nikulin writes:


My guess is that GPLv2 BASH on macOS does not support associative
arrays. Perhaps these tests should be skipped if BASH_VERSION is not
fresh enough (not supplied by Apple).


https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e4ab416fc


Feature detection should be more reliable.

;; Old GPLv2 BASH in macOSX does not support associative arrays.
(if-let ((bash (executable-find "bash")))
(eq 0 (process-file
   bash nil nil nil
   "-c" "declare -A assoc_array")))

Even version check may be performed by shell

(if-let ((bash (executable-find "bash")))
(eq 0 (process-file
   bash nil nil nil
   "-c" "[ ${BASH_VERSINFO[0]} -ge 4 ]")))

Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM

[Alexander Adolf]

Ihor Radchenko  writes:

> Bastien Guerry  writes:
>
>> Ihor Radchenko  writes:
>>
>>> Thanks!
>>> The patch is ready to be merged.
>>> Bastien, may you please confirm the FSF records?
>>> Alexander should have the copyright signed.
>>
>> Yes, he has, thanks!
>
> Applied, onto main.
> [...]
> Thanks for your contribution!

Many thanks for your kind support in getting it in shape; much
appreciated. It was my pleasure working with you!

One last question though: I'm developing an add-on package which will
use the new features. I guess in "Package-Requires:" it should say
(org "9.7") ?

> [...]
> Your name have been added to our contributor list:
> https://git.sr.ht/~bzg/worg/commit/73d38812
> [...]

More than I deserve...


Many thanks and cheers,

  --alexander

Re: keeping subtree heading on export

[Ihor Radchenko]

Matt Price  writes:

> ... I need to export each individual page
> of the "book" to its own markdown page.  However, jupyter-book expects to
> find the title of the page in the initial first-level heading.  So I'd like
> to retain the subtree "title" as a first-level heading, and demote the
> remaining headings to their original state within the larger org document.
>
> Does anyone know of an existing exporter that already does this, from which
> I can steal? Or if not, how would you suggest I go about doing this?

May you provide an example demonstrating initial Org mode document and
how the exported md documents should look like?

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

Re: [PATCH] ob-lua: Support all types and multiple values in results

[Ihor Radchenko]

Rudolf Adamkovič  writes:

> Ihor Radchenko  writes:
>
>> May you create a test for this with expected failure?
>
> Sure!  Here is one:
>
>   (should
>(equal "{B}"
>   (org-test-with-temp-text
>   "src_lua{return string.match('A {B} C', '%b{}')}"
> (org-babel-execute-src-block
>
> The return value from 'string.match' is the substring "{B}", which Babel
> misjudges to be a list and signals the error:
>
>   (user-error "Inline error: list result cannot be used")

Maybe something like the attached.
(I am a casual lua user, so better double check)

>From bfe0fa3d78cc13b84dec33c230755c9f4693a685 Mon Sep 17 00:00:00 2001
Message-ID: 
From: Ihor Radchenko 
Date: Fri, 26 Apr 2024 16:39:07 +0300
Subject: [PATCH] ob-lua: Fix edge case when output is {string}
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lisp/ob-lua.el (org-babel-lua-wrapper-method): Make sure that string
result is enclosed in "...", so that Org mode does not try to guess
the output type heuristically.
* testing/lisp/test-ob-lua.el (test-ob-lua/types): New test.

Co-authored-by: Rudolf Adamkovič 
---
 lisp/ob-lua.el  | 2 ++
 testing/lisp/test-ob-lua.el | 6 ++
 2 files changed, 8 insertions(+)

diff --git a/lisp/ob-lua.el b/lisp/ob-lua.el
index 041abfabc..afe88065d 100644
--- a/lisp/ob-lua.el
+++ b/lisp/ob-lua.el
@@ -282,6 +282,8 @@ (defvar org-babel-lua-wrapper-method
  end
   end
   return result
+   elseif type(it) == 'string' then
+  return '\"' .. it .. '\"'
else
   return tostring(it)
end
diff --git a/testing/lisp/test-ob-lua.el b/testing/lisp/test-ob-lua.el
index 0a60c68ca..398ab761d 100644
--- a/testing/lisp/test-ob-lua.el
+++ b/testing/lisp/test-ob-lua.el
@@ -158,6 +158,12 @@ (ert-deftest test-ob-lua/types ()
(equal "hello world"
   (org-test-with-temp-text "src_lua{return 'hello world'}"
 (org-babel-execute-src-block
+  ;; Edge case: string matching list syntax.
+  (should
+   (equal "{B}"
+	  (org-test-with-temp-text
+	  "src_lua{return string.match('A {B} C', '%b{}')}"
+	(org-babel-execute-src-block
   (should
(equal 0
   (string-match "table: 0x[0-9A-F]+"
-- 
2.44.0


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

Re: org-babel: complete control over org-babel-execute-src-block behavior

[Ihor Radchenko]

Justin Veilleux  writes:

> Hi. I'm currently trying to write a org-babel-julia backend and I am
> having problems. The way I wanted it to work is by executing the code,
> and then inserting the results block manually using
> `org-babel-insert-result`. I would have passed either :output or a mime
> type (such as application/org) to the julia function and received
> correctly formatted (with the format function extendable from the julia
> side) text.
>
> However, as I understand it, the result of the org-babel-execute:julia
> function will be modified by the org babel infrastructure (with regards
> to the src block params).
>
> Is there a way to bypass this so that I can offload the data
> transformation as much as possible to the julia side?

I strongly discourage you from doing such thing.
There is a reason Org babel wants the output to be in Elisp form, not in
the final Org mode form - `org-babel-execute-src-block' takes care about
processing various user customizations, like :file and :post header
arguments; and respecting user choices about result type.

If you want to generate Org mode markup as the output of your babel
backend, you can simply set the default result type to raw in
org-babel-default-header-args:julia. Then, if your
org-babel-execute:julia returns a string containing Org markup, it will
be interpreted as Org, unless the user explicitly chooses otherwise.

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

Re: [PATCH] Re: [BUG] ob-shell: :shebang changes interpretation of :cmdline

[Ihor Radchenko]

Max Nikulin  writes:

> Actually script arguments (and :stdin) might be applied to python and at 
> least some other languages, so support of this feature should be moved 
> from ob-shell to common org-babel code.
>
> My point:
> - header arguments should have as close as possible meaning across 
> various languages.
> - withing ob-shell variation of ways to execute a script should be 
> minimized either some parameters (:cmdline, :shebang, :stdin) are 
> specified or not.

+1
ob-eval is a good candidate to implement such unified handling.

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

[DISCUSSION] The meaning of :cmdline header argument across babel backends (was: [PATCH] Re: [BUG] ob-shell: :shebang changes interpretation of :cmdline)

[Ihor Radchenko]

Max Nikulin  writes:

> However looking wider, I do not like that :cmdline for ob-shell has 
> different meaning than for other languages, see e.g. ob-sql. Only for 
> shell this parameter is treated as arguments of a *script*. In other 
> cases :cmdline is used to specify arguments of *interpreter* and I think 
> ob-shell should follow this convention.

Alas, we already have the current state of affairs documented in
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-shell.html#orge70bc7b

So, no breaking changes.

And shell scripts are not like SQL queries - they often do need to check
arguments. So, the current behaviour is justified, IMHO.

For some languages, only switches to the interpreter make sense (ditaa,
lilypond, plantuml). For others, (bash, python, C++, etc), we may want
to pass switches to the script itself more often.

What might be done is introducing _two_ different header arguments - one
for interpreter switches, and another for script/program switches.

Say, :interpreter-cmdline and :script-cmdline.
Then, we can call the current :cmdline behaviour "dwim" and allow users
to be more explicit if necessary.

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

Re: [BUG] org-forward-paragraph [9.6.6 (release_9.6.6 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]

[Ihor Radchenko]

[ Adding Org mailing list back to CC.
  Please use Reply All or Wide reply to keep the conversation public ]

> Okay I can't reproduce with emacs -Q

The next step is trying to pinpoint what is causing the problem in your
config. If it is some Org mode option, please let us know.

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

Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM

[Ihor Radchenko]

Bastien Guerry  writes:

> Ihor Radchenko  writes:
>
>> Thanks!
>> The patch is ready to be merged.
>> Bastien, may you please confirm the FSF records?
>> Alexander should have the copyright signed.
>
> Yes, he has, thanks!

Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5a98b4c56
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4e6fa96e2
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=fbf613ece

Thanks for your contribution!

Your name have been added to our contributor list:
https://git.sr.ht/~bzg/worg/commit/73d38812

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

Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM

[Bastien Guerry]

Ihor Radchenko  writes:

> Thanks!
> The patch is ready to be merged.
> Bastien, may you please confirm the FSF records?
> Alexander should have the copyright signed.

Yes, he has, thanks!

-- 
 Bastien Guerry

Re: PATCH allow explicit style= in #+cite_export: biblatex

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

> Hopefully all remarks addressed..
> Best, /PA

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

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

Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM

[Ihor Radchenko]

Alexander Adolf  writes:

> Ihor Radchenko  writes:
>
>> [...]
 If you can, please add some more tests like mine checking
 `org-columns--clean-item'.
>> [...]
>
> I have added one test for each new feature (headline linkification, and
> formatting function). Also, there's a third patch, which moves the call
> to `org-quote-vert' to the cleanup function `org-columns--clean-item' as
> you suggested.
>
> Updated patches below.

Thanks!
The patch is ready to be merged.
Bastien, may you please confirm the FSF records?
Alexander should have the copyright signed.

> One more thing caught my eye in `org-dblock-write:columnview' though.
> When running the currently (i.e. before my patches) last test in
> test-org-colview.el, the one with `org-columns-default-format' set to
> "%ITEM %DEADLINE(d) %SCHEDULED(s) %TIMESTAMP(t)", `org-with-wide-buffer'
> appears to modify the buffer and advances point by one (before the call
> point is at 97, after the call at 98). In all other tests,
> `org-with-wide-buffer' does not move point. In
> `org-dblock-write:columnview' I have thus moved the sampling of point
> for passing to the formatting function to after the call to
> `org-with-wide-buffer'.

This is expected - `org-dblock-write:columnview' uses
`org-columns--capture-view', which, in turn, calls the `org-columns' -
function used to create an interactive column view.

For interactive column view, we must have at least a single space for
each column. Otherwise, we cannot display the columns overlay. So,
`org-columns' always add spaces to headlines, when there are not enough
of them to fit all the requested columns.

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

Re: org-clock-display calculate clock time record wrong

[Ihor Radchenko]

"Christopher M. Miles"  writes:

> I run "org-clock-display" command on an Org file. Here is the screenshot:

See `org-clock-display-default-range'.

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

Re: [BUG] org-forward-paragraph [9.6.6 (release_9.6.6 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]

[Ihor Radchenko]

Joe Gilder  writes:

> org-forward-paragraph stops working when it reaches a line that begins with an
> org-link.
>
> It throws off this error:
>
> org-forward-paragraph: Wrong type argument: integer-or-marker-p, nil
>
> For example, in the following text, org-forward-paragraph gets stuck on that 
> first line with the link.
>
> ==
>
> [[file:/Users/joegilder/Emacs/Files/202404/25093732/20240425093838_CPCS 
> Songbook - April 28th 2024.pdf]]
>
>
> So sorry...hit send early by mistake...here is the finished email..  I think 
> my pain levels contributed to that.

I am unable to reproduce the problem using the latest stable Org mode
and using Org mode shipped with Emacs 29.3.

May you please provide a reproducer starting from emacs -Q?
See https://orgmode.org/manual/Feedback.html

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

Re: [PATCH] Re: [BUG] ob-shell: :shebang changes interpretation of :cmdline

[Ihor Radchenko]

Ihor Radchenko  writes:

> Max Nikulin  writes:
>
>>> +shell-file-name
>> ...
>>> +(list shell-command-switch
>>> +  (concat (file-local-name script-file)  " " 
>>> cmdline
>>
>> Using `shell-command-switch' unconditionally may lead to executing 
>> /bin/sh instead of shell specified by `shell-file-name' for script files 
>> having no shebang, see
>>
>> https://superuser.com/questions/502984/writing-shell-scripts-that-will-run-on-any-shell-using-multiple-shebang-lines
>
> Good point.

I am looking at this again, and notice that the problem with
`shell-command-switch' is tangent to the original bug report we are
discussing.

Currently, ob-shell uses two ways to execute the source block:

1. When :shebang header argument is provided,
''

2. When :shebang is not provided
 ' '

The problem you linked to only manifests for calling script files
_without_ shebang, while the original bug report is about the case when
:shebang is given.

I conclude that your concern, while being valid, is a _different_ bug.
Thus, I do not see it as a blocker for my patch - my patch will fix the
*original bug reported on top of this thread*.

As for the problem with   
when  does not contain shebang, we can trivially at that
shebang like

(with-temp-file script-file
(if shebang (insert shebang "\n")
  (insert "#!" shell-file-name "\n"))
(when padline (insert "\n"))
(insert body))

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

Re: FAILED test-ob-shell/bash-uses-assoc-arrays

[Ihor Radchenko]

Max Nikulin  writes:

>>> My guess is that GPLv2 BASH on macOS does not support associative
>>> arrays. Perhaps these tests should be skipped if BASH_VERSION is not
>>> fresh enough (not supplied by Apple).
>> 
>> I guess so. Which bash versions should we cut off?
>
> /usr/share/doc/bash/NEWS.gz
>> This is a terse description of the new features added to bash-4.0 since
>> the release of bash-3.2.  As always, the manual page (doc/bash.1) is
>> the place to look for complete descriptions.

Done, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e4ab416fc

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

Re: [PATCH] ox-publish: Do not store :title, :date, and :index in project cache

[Ihor Radchenko]

Ihor Radchenko  writes:

> This patch fixes situation when :title/:date/:index properties are
> stored in the project cache and then not updated even when the
> corresponding project file does get updated.

Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=510e8f9cc

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

Re: [BUG] HTML export does not preserve footnote label [9.6.15 (release_9.6.15 @ /usr/local/share/emacs/30.0.50/lisp/org/)]

[Max Nikulin]

On 26/04/2024 15:17, Protesilaos Stavrou wrote:

Since we are now using labels for the HTML export, I think it makes
sense to optionally use those for the anchor tags as well.

[...]


+(defcustom org-html-footnote-use-label-for-anchor-text nil


Another option may be to rely on the existing one: 
`org-html-prefer-user-labels'

Re: [BUG] bug in 'ox-man?

[Ihor Radchenko]

Ihor Radchenko  writes:

>> presumably one might have backslash sequences in example blocks, or in
>> the main text, or ...?  i don't know enough to have any idea if there is
>> some general mechanism that might solve all those.
>
> See the attached tentative patch.

Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=68d592bae

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

org-babel: complete control over org-babel-execute-src-block behavior

[Justin Veilleux]

Hi. I'm currently trying to write a org-babel-julia backend and I am
having problems. The way I wanted it to work is by executing the code,
and then inserting the results block manually using
`org-babel-insert-result`. I would have passed either :output or a mime
type (such as application/org) to the julia function and received
correctly formatted (with the format function extendable from the julia
side) text.

However, as I understand it, the result of the org-babel-execute:julia
function will be modified by the org babel infrastructure (with regards
to the src block params).

Is there a way to bypass this so that I can offload the data
transformation as much as possible to the julia side?

Thanks.

HowTo: Upgrade org-mode installation from the command-line

[Cook, Malcolm]

The section on org-mode 
[[https://orgmode.org/org.html#Installation][Installation]] entitled "Using 
Emacs packaging
system" might be improved with the following advice:

** Upgrade org-mode installation from the command-line

The Emacs packaging system can be used to upgrade an org-mode
installation from linux command-line by running emacs in batch mode:

#+begin_src sh
EMACS=emacs # /usr/local/bin/emacs
EMACSQBE=${EMACS} -Q -batch -eval
${EMACSQBE} "(progn (require 'package) (package-initialize) 
(package-refresh-contents) (package-upgrade 'org))"
#+end_src

This approach has the advantage of isolating the upgrade process for
any other running emacs session, ensuring that version conflicts can
not arise.

Note: For the upgraded version to be loaded by emacs, you mush place
`package-initialize` early in your init.el.  Failure to do so will
result in the old system version to be loaded, as can be seen:

#+begin_src sh :results output
${EMACSQBE} "(progn   (print (org-version 'org)))"
${EMACSQBE} "(progn  (package-initialize) (print (org-version 'org)))"
#+end_src

#+RESULTS:
: 
: "9.6.15"
: 
: "9.6.27"


Note further that if the above upgrade command was done in an emacs
shell buffer, you will need to restart emacs to pick up the updated
package.  Failing to do so will result in `meta-x org-version`
reporting the old version:

#+begin_src src
Org mode version 9.6.15 (release_9.6.15 @ 
/usr/local/share/emacs/30.0.50/lisp/org/)
#+end_src

but after restart with my init.el file it reports:

#+begin_src src
Org mode version 9.6.27 ( @ /home/mec/.dotfiles/emacs/.emacs.d/elpa/org-9.6.27/)
#+end_src

Can we add PLOT to org-element-multiple-keywords?

[Jeff Trull]

Hi all,

I notice that multiple #+PLOT lines before a table will be coalesced and
handled as one. However, this is
accomplished through specific code in org-plot.el that does a reverse
search through the buffer for
additional lines. org-element has a built-in mechanism for this,
org-element-multiple-keywords. It seems
like it would be useful to add PLOT to it. Can that be done? If not, is
there a way to temporarily add it for
an exporter?

Thanks,
Jeff

Re: [BUG] HTML export does not preserve footnote label [9.6.15 (release_9.6.15 @ /usr/local/share/emacs/30.0.50/lisp/org/)]

[Protesilaos Stavrou]

Hello again!

A follow-up on the patches below:

> From: Protesilaos Stavrou 
> Date: Fri, 26 Apr 2024 10:55:50 +0300

> [... 41 lines elided]

> Thank you! I just tried it. I encountered two problems with it, which I
> am addressing with the two attached patches (feel free to modify as
> needed). In short:
>
> 1. The footnote definitions at the bottom of the file were still using
> the ordinal HTML id, which did not correspond to the href with the
> label.
>
> 2. If the file had a mixture of labeled and anonymous/unlabeled
> footnotes, then the export would break as it would be passing a nil
> value to 'string-to-number'.
>
> Please let me know how to proceed.

Since we are now using labels for the HTML export, I think it makes
sense to optionally use those for the anchor tags as well.

See the attached patch for a possible way of doing this.

As always, you are welcome to make any further changes.

-- 
Protesilaos Stavrou
https://protesilaos.com
>From 681db0934e55ae6c2971ccfbfd9de7c0828506c9 Mon Sep 17 00:00:00 2001
Message-Id: <681db0934e55ae6c2971ccfbfd9de7c0828506c9.1714119282.git.i...@protesilaos.com>
From: Protesilaos Stavrou 
Date: Fri, 26 Apr 2024 11:14:28 +0300
Subject: [PATCH] Provide option to use footnote label as the HTML anchor text

* lisp/ox-html.el (org-html-footnote-use-label-for-anchor-text):
Define new user option.
(org-html-footnote-section, org-html-footnote-reference): Use the new
option.
---
 lisp/ox-html.el | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 0237e61..804a464 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -699,6 +699,17 @@ (defcustom org-html-footnote-separator ", "
   :group 'org-export-html
   :type 'string)
 
+(defcustom org-html-footnote-use-label-for-anchor-text nil
+  "When non-nil, use the footnote label as the anchor text.
+When nil, use the number of the footnote as the anchor text.
+
+- For footnotes, this is the format: [fn:LABEL].
+- For inline footnotes, it is this: [fn:LABEL: Some text]."
+  :group 'org-export-html
+  :version "30.1"
+  :package-version '(Org . "9.7")
+  :type 'boolean)
+
  Headline
 
 (defcustom org-html-toplevel-hlevel 2
@@ -1900,7 +1911,9 @@ (defun org-html-footnote-section (info)
 (if label
 			(format "fn.%s" label)
 			  (format "fn.%d" n))
-			n
+(if (and org-html-footnote-use-label-for-anchor-text label)
+label
+  n)
 			(format " class=\"footnum\" href=\"#fnr.%s\" role=\"doc-backlink\"" (or label n))
 			info))
 		   (contents (org-trim (org-export-data def info
@@ -2768,7 +2781,11 @@ (defun org-html-footnote-reference (footnote-reference _contents info)
  (format
   (plist-get info :html-footnote-format)
   (org-html--anchor
-   id n (format " class=\"footref\" href=\"#fn.%s\" role=\"doc-backlink\"" (or label n)) info)
+   id
+   (if (and org-html-footnote-use-label-for-anchor-text label)
+   label
+ n)
+   (format " class=\"footref\" href=\"#fn.%s\" role=\"doc-backlink\"" (or label n)) info)
 
  Headline
 
-- 
2.39.2

Re: [BUG] HTML export does not preserve footnote label [9.6.15 (release_9.6.15 @ /usr/local/share/emacs/30.0.50/lisp/org/)]

[Protesilaos Stavrou]

> From: Ihor Radchenko 
> Date: Sat, 13 Apr 2024 14:00:48 +
>
> Protesilaos Stavrou  writes:
>
>> With regard to the disambiguation scheme, I am playing around with
>> various scenaria to see how Org HTML export behaves. Using the
>> following:
>> ...
>> This is test 2 > role="doc-backlink">1
>> ...
>> This is test 3 > role="doc-backlink">1
>>
>> Notice that the 100 in the ID is not incremented further. I guess this
>> is something that can be worked on but, again, I think it is separate
>> from the issue of using the label for the ID and HREF.
>>
>> Any thoughts?
>
> Duplicate IDs are against HTML spec:
> https://softwareengineering.stackexchange.com/questions/127178/two-html-elements-with-same-id-attribute-how-bad-is-it-really
>
> So, this is a bug.

Indeed! We can look into this separately.

 Though I should have clarified my intent earlier: the idea is to use the
 label as a fixed reference to the footnote, so that the link does not
 change between exports. This is the same principle as what we do with
 links to headings that have a CUSTOM_ID.

 As such, the anchor text can still be the way it is now as an
 automatically generated number sequence (^1, ^2, etc.), but the HTML
 "id" and "href" values will be constructed based on the label of the
 footnote, NOT its number in the sequence.
>
> See the attached tentative patch.

> [... 144 lines elided]

Thank you! I just tried it. I encountered two problems with it, which I
am addressing with the two attached patches (feel free to modify as
needed). In short:

1. The footnote definitions at the bottom of the file were still using
the ordinal HTML id, which did not correspond to the href with the
label.

2. If the file had a mixture of labeled and anonymous/unlabeled
footnotes, then the export would break as it would be passing a nil
value to 'string-to-number'.

Please let me know how to proceed.

-- 
Protesilaos Stavrou
https://protesilaos.com
>From 0fb81645aafb780116465e13758601ff1183e043 Mon Sep 17 00:00:00 2001
Message-Id: <0fb81645aafb780116465e13758601ff1183e043.1714117826.git.i...@protesilaos.com>
From: Protesilaos Stavrou 
Date: Fri, 26 Apr 2024 10:41:51 +0300
Subject: [PATCH 1/2] Use the label, if present, in footnote definition

* lisp/ox-html.el (org-html-footnote-section): Account for a non-nil
  label value.
---
 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 aa0f891..95ecb44 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -1896,7 +1896,9 @@ (defun org-html-footnote-section (info)
 	 (let ((inline? (not (org-element-map def org-element-all-elements
  #'identity nil t)))
 		   (anchor (org-html--anchor
-			(format "fn.%d" n)
+(if label
+			(format "fn.%s" label)
+			  (format "fn.%d" n))
 			n
 			(format " class=\"footnum\" href=\"#fnr.%s\" role=\"doc-backlink\"" (or label n))
 			info))
-- 
2.39.2

>From 112c5671e5f55ea1d9e5e9fb6dd647e6a739c9ac Mon Sep 17 00:00:00 2001
Message-Id: <112c5671e5f55ea1d9e5e9fb6dd647e6a739c9ac.1714117826.git.i...@protesilaos.com>
In-Reply-To: <0fb81645aafb780116465e13758601ff1183e043.1714117826.git.i...@protesilaos.com>
References: <0fb81645aafb780116465e13758601ff1183e043.1714117826.git.i...@protesilaos.com>
From: Protesilaos Stavrou 
Date: Fri, 26 Apr 2024 10:49:26 +0300
Subject: [PATCH 2/2] Guard against nil label value for footnotes

* lisp/ox-html.el (org-html-footnote-section)
(org-html-footnote-reference): Check if label is a string before
passing it to 'string-to-number'.

This fixes the case where we are exporting some footnotes with a label
and some without a label.
---
 lisp/ox-html.el | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 95ecb44..0237e61 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -1886,7 +1886,8 @@ (defun org-html-footnote-section (info)
  ;; - the footnotes are re-numbered by
  ;; `org-export-get-footnote-number'.  If the label is not
  ;; a number, keep it.
- (when (equal label (number-to-string (string-to-number label)))
+ (when (and (stringp label)
+(equal label (number-to-string (string-to-number label
(setq label nil))
 	 ;; `org-export-collect-footnote-definitions' can return
 	 ;; two kinds of footnote definitions: inline and blocks.
@@ -2754,8 +2755,10 @@ (defun org-html-footnote-reference (footnote-reference _contents info)
   ;; the footnotes are re-numbered by
   ;; `org-export-get-footnote-number'.  If the label is not a
   ;; number, keep it.
-  (label (if (equal label (number-to-string (string-to-number label)))
- nil label))
+  (label (if (and (stringp label)
+  (equal label (number-to-string (string-to-number