How does =org-md-item= produce the correct indentation for nested lists?

[Rohit Patnaik]

Hello,

I was looking at the implementation for =org-md-item=, in ox-md.el, and I'm
wondering how indentation logic for nested lists works. Specifically, I was
looking at the following code:

#+BEGIN_SRC elisp
(concat bullet
(make-string (- 4 (length bullet)) ? )
(pcase (org-element-property :checkbox item)
  (`on "[X] ")
  (`trans "[-] ")
  (`off "[ ] "))
(let ((tag (org-element-property :tag item)))
  (and tag (format "**%s:** "(org-export-data tag info
(and contents
 (org-trim (replace-regexp-in-string "^" "" contents
#+END_SRC

and I'm wondering why it's adding indentation in front of the bullet. Naively, I
would expect the result of this snippet, for an unordered list to be something
like:

=-[item contents]=

That is, it concatenate the bullet, then three spaces (4 - length of bullet),
then another four spaces, then the contents of the item. Instead, what I see is
a four-space indent, followed by the bullet and its padding, followed by the
item contents:

=-   [item contents]=

This is the correct result, but I don't see how the code from ox-md.el produces
that result.

The reason I'm asking is because I have similar logic in the org-mode exporter
I'm writing for PMWiki markup:

https://github.com/quanticle/ox-pmwiki/blob/master/ox-pmwiki.el#L214

and I would like to change the logic so that instead of indenting with spaces,
it repeats the list marker (** for a second level nested list, *** for 3 levels
of nesting, etc). 

Thanks,
Rohit Patnaik

Re: [BUG] Org parser error when removing latex preview [9.6.15 (release_9.6.15 @ /gnu/store/gnvv2a1nxfbibkm1wdxdv6bd6mhk4cf8-emacs-29.3/share/emacs/29.3/lisp/org/)]

[General discussions about Org-mode.]

> From: Ihor Radchenko 
> Date: Fri, 12 Apr 2024 18:24:17 +
>
> Anush V via "General discussions about Org-mode."
>  writes:
>
>> Below are the steps to replicate the issue:
>>
>> Start emacs by running "emacs --no-init".
>>
>> Set the org-startup-numerated variable to true with the command (setq
>> org-startup-numerated t).
>>
>> Create a new file named tmp.org and insert the following content:
>>
>> - H
>> $\alpha$
>>
>> To view the latex equation, place the cursor on the equation and press
>> the shortcut C-c C-x C-l to run org-latex-preview.  This will display
>> the latex preview.
>>
>> Press C-c C-x C-l again to remove the latex preview and receive the
>> warning:
>>
>>
>>
>> ■ Warning (org-element-cache): org-element--cache: Org parser error in 
>> tmp.org::11. Resetting.
>> The error was: (error "Invalid search bound (wrong side of point)")
>> Backtrace: nil
>> Please report this issue to the Org mode mailing list using M-x 
>> org-submit-bug-report.
>
> Thanks for reporting!
> I tried to follow your steps, but I am unable to reproduce the problem.
> May you please attach the exact problematic Org file, so that we can
> make sure that we do the same thing?

Thanks for the prompt response.

Please find the attached file tmp.org.

Please ensure that the LaTeX preview image for the equation ($\alpha$)
is not in the directory specified by org-preview-latex-image-directory.
This warning appears when you generate a preview image that is not
already present in the directory specified by
org-preview-latex-image-directory.  I should have clarified this in the
initial email.  Apologies for any confusion.

-- 
Anush Veeranala
- H
$\alpha$

Re: [PATCH] Ensure org-table-header displays without cursor inside table

[Lei Zhe]

Great, thanks.


On Sat, Apr 13, 2024 at 2:04 AM Ihor Radchenko  wrote:

> Bastien Guerry  writes:
>
> > Ihor Radchenko  writes:
> >
> >> P.S. Bastien, may your please check Lei Zhe's copyright status?
> >
> > Yes, I confirm Lei Zhe copyright status is okay.
>
> Applied, onto bugfix. I amended the commit author field to contain the
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5128460f9
> full name.
>
> Lei Zhe, you are now listed as an Org contributor. Thank you!
> https://git.sr.ht/~bzg/worg/commit/104102ff
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)

[Jim Porter]

On 4/12/2024 5:41 AM, Ihor Radchenko wrote:

Jim Porter  writes:


That sounds reasonable enough to me; does anyone else have opinions on
this? Otherwise, I'll get to work on a patch (though probably not for a
couple weeks).


It has been a while since the last message in this thread.
Jim, may I know if you had a chance to work on the patch?


Sorry about that. I'm currently extremely swamped with real life, but 
most of that should be wrapped up by the end of the month, at which 
point I'll be able to devote some time to Emacs again.

Re: [BUG] Org parser error when removing latex preview [9.6.15 (release_9.6.15 @ /gnu/store/gnvv2a1nxfbibkm1wdxdv6bd6mhk4cf8-emacs-29.3/share/emacs/29.3/lisp/org/)]

[Ihor Radchenko]

Anush V via "General discussions about Org-mode."
 writes:

> Below are the steps to replicate the issue:
>
> Start emacs by running "emacs --no-init".
>
> Set the org-startup-numerated variable to true with the command (setq
> org-startup-numerated t).
>
> Create a new file named tmp.org and insert the following content:
>
> - H
> $\alpha$
>
> To view the latex equation, place the cursor on the equation and press
> the shortcut C-c C-x C-l to run org-latex-preview.  This will display
> the latex preview.
>
> Press C-c C-x C-l again to remove the latex preview and receive the
> warning:
>
>
>
> ■ Warning (org-element-cache): org-element--cache: Org parser error in 
> tmp.org::11. Resetting.
> The error was: (error "Invalid search bound (wrong side of point)")
> Backtrace: nil
> Please report this issue to the Org mode mailing list using M-x 
> org-submit-bug-report.

Thanks for reporting!
I tried to follow your steps, but I am unable to reproduce the problem.
May you please attach the exact problematic Org file, so that we can
make sure that we do the same thing?

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

Re: #7 [[bbb:OrgMeetup]] on Wed, Apr 24, 19:00 UTC+3

[Matt]

  On Wed, 10 Apr 2024 10:33:15 +0200  Ihor Radchenko  wrote --- 

 > Another OrgMeetup will be scheduled on the last Wednesday of February,
 > in two weeks. (Sorry, I cannot make it second Wednesday this time, and
 > even third.)

Thanks for running this.  I look forward to it :) 

--
Matt Trzcinski
Emacs Org contributor (ob-shell)
Learn more about Org mode at https://orgmode.org
Support Org development at https://liberapay.com/org-mode

Re: [PATCH] Ensure org-table-header displays without cursor inside table

[Ihor Radchenko]

Bastien Guerry  writes:

> Ihor Radchenko  writes:
>
>> P.S. Bastien, may your please check Lei Zhe's copyright status?
>
> Yes, I confirm Lei Zhe copyright status is okay.

Applied, onto bugfix. I amended the commit author field to contain the
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5128460f9
full name.

Lei Zhe, you are now listed as an Org contributor. Thank you!
https://git.sr.ht/~bzg/worg/commit/104102ff

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

Re: [PATCH] org-faq.org: rename org-export-htmlize-* options to org-html-htmlize-*

[Ihor Radchenko]

Ihor Radchenko  writes:

> Rudolf Adamkovič  writes:
>
>> While you are on it, ...
>> ...
>
> See the attached updated patch.

Applied, onto master.
https://git.sr.ht/~bzg/worg/commit/dcb2c11c

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

Re: Bug: org-no-popups disregards display-buffer-fallback-action [9.4.6 (9.4.6-13-g4be129-elpaplus @ /home/jeeger/.emacs.d/elpa/org-plus-contrib-20210920/)]

[Ihor Radchenko]

Daniel Kraus  writes:

> Eric S Fraga  writes:
>
>> On Monday, 15 Nov 2021 at 00:03, dal-bla...@onenetbeyond.org wrote:
>>> So if we want to make org cooperate with window.el we must ban theses
>>> functions and instead delegate the window management with calls to
>>> proper display functions.
>>
>> I agree completely.  One of my bug-bears is org-capture which I often
>> use during meetings to take notes or create TODO items.  Typically, the
>> org capture window covers my Teams buffer (I use exwm as my window
>> manager...) which is rather annoying.
>>
>> I did play with display-buffer-alist but it seemed to not be able to
>> take control of some of org's windows.  Everything else I do in Emacs is
>> nicely managed through that alist.
>
> Just want to mention that I would also really appreciate this.
> I asked for it ~4 years ago on this list 
> https://lists.gnu.org/archive/html/emacs-orgmode/2017-12/msg00241.html
> and it also comes up from time to time in other places
> like this Reddit thread 
> https://www.reddit.com/r/emacs/comments/ic4u1m/stop_emacs_from_hiding_other_windows_when/

I believe that `display-buffer-alist' is fully obeyed now by Org mode (on
main branch). A few exceptions are when `org-agenda-window-setup' or/and
`org-src-window-setup' are customized to non-default value - then Org
does what the user asked for.

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

Re: Verbatim content (inline-special-block)

[Ihor Radchenko]

Max Nikulin  writes:

>> It may be enough to have @kbd{@code{...}} - it is not like Texinfo has a
>> concept of truly verbatim text like in Org.
>> 
>> Alternatively, we may allow two classes of inline markup:
>> @foo{parsed *text* inside}
>> and
>> @foo={verbatim *text* inside}/@foo~{verbatim *text* inside}
>> 
>> This way, instead of @code{}, we should use @code~{...} or even
>> @~{...}/@={...} (mnemonics for ~...~ and =...=)
>
> I consider @foo={}-like variants as unnecessary complications of the 
> inline special block feature. The idea of composition is better from my 
> point of view. With this approach it is enough to have non-conflicting 
> syntax for non-parsed fragments. I am against making @code{} a special 
> name with suppressed markup parsing. The price of composition in 
> comparison with @foo={} is more verbose markup.

Then, do you have an idea about such syntax?

One option I thought of was making @foo{=...=} a special type of boundary
delimiting non-parsing contents. However, it is not very elegant IMHO.

> By the way, Org has src_lang{...} syntax for almost non-parsed fragments 
> (neglecting requirement of balanced curly brackets that is an issue).

Yes, but it is handled differently by exporters from =verbatim=/~code~.
In fact, even the idea with @foo{@code{...}} may be problematic in this
regard - @code{...} inside, if we treat it as an equivalent of ~code~,
may be problematic if some export backends do something unusual about
code markup.

> Actually "=" in @foo={} is a kind of special argument distinct from ones 
> specified inside [] and {}.

Yes, but it is much easier to parse. If we use a proper attribute, we
run into all kind of issues with how consistent it should be with the
parsing rules for other attributes (should it be inherited? may it
appear in arbitrary place in [...]?). And if we make it special, we will
run in various special cases in the parser...

>>>   @code{def calculate(@param{expr}, @param{env})}
> [...]
>> Also, the reason why Texinfo users do @param in @code is the lack of
>> automatic syntax highlighting, unlike in Org mode.
>
> Is ox-texinfo able to convert syntax highlighting to native texinfo markup?

No.

> So if @markup{} is not allowed in verbatim content then it is another 
> feature loosely related to custom inline blocks.

May you elaborate?

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

(error "Listing directory failed but ‘access-file’ worked")

[Edgar Lux]

Hello.

I got this in an Org file:

#+begin_src org
[[file:Figures/Ti19-g(w, eta={0.1,}, R=1e-3).svg]]
[[file:Figures/Ti19-g(w, eta={0.1,}, R=1e-3).png]]
#+end_src

The files exist, and can be viewed in image-mode (tested with src_bash{emacs 
-q}).
With =C-c C-o= src_emacs-lisp{(org-open-at-point)}, the result is:

#+begin_example
Debugger entered--Lisp error: (error "Listing directory failed but 
‘access-file’ worked")
  signal(error ("Listing directory failed but ‘access-file’ worked"))
  error("Listing directory failed but `access-file' worked")
  insert-directory("/tmp/Figures/Ti19-g(w, eta={0.1,}, R=1e-3).svg" "--dired 
-alth --group-directories-first" t nil)
  dired-insert-directory("/tmp/Figures/Ti19-g(w, eta={0.1,}, R=1e-3).svg" 
"-alth --group-directories-first" nil t t)
  dired-readin-insert()
  #f(compiled-function () #)()
  combine-change-calls-1(1 1 #f(compiled-function () #))
  dired-readin()
  dired-internal-noselect("/tmp/Figures/Ti19-g(w, eta={0.1,}, R=1e-3).svg" nil)
  dired-noselect("Figures/Ti19-g(w, eta={0.1,}, R=1e-3).svg" nil)
  dired("Figures/Ti19-g(w, eta={0.1,}, R=1e-3).svg")
  (if (string-match "[*?{]" (file-name-nondirectory file-name)) (dired 
file-name) (apply #'org-open-file file-name arg (cond ((not option) nil) 
((string-match-p "\\`[0-9]+\\'" option) (list (string-to-number option))) (t 
(list nil option)
  (let* ((option (and (string-match "::\\(.*\\)\\'" path) (match-string 1 
path))) (file-name (if (not option) path (substring path 0 (match-beginning 
0) (if (string-match "[*?{]" (file-name-nondirectory file-name)) (dired 
file-name) (apply #'org-open-file file-name arg (cond ((not option) nil) 
((string-match-p "\\`[0-9]+\\'" option) (list (string-to-number option))) (t 
(list nil option))
  org-link-open-as-file("Figures/Ti19-g(w, eta={0.1,}, R=1e-3).svg" nil)
  (let* ((option (org-element-property :search-option link)) (path (if option 
(concat path "::" option) path))) (org-link-open-as-file path (let* ((val 
(org-element-property :application link))) (cond (arg (let nil arg)) ((equal 
val '"emacs") (let nil 'emacs)) ((equal val '"sys") (let nil 'system))
  (let nil (let* ((option (org-element-property :search-option link)) (path (if 
option (concat path "::" option) path))) (org-link-open-as-file path (let* 
((val (org-element-property :application link))) (cond (arg (let nil arg)) 
((equal val '"emacs") (let nil 'emacs)) ((equal val '"sys") (let nil 
'system)))
  (cond ((equal type '"file") (let nil (let* ((option (org-element-property 
:search-option link)) (path (if option (concat path "::" option) path))) 
(org-link-open-as-file path (let* ((val ...)) (cond (arg ...) (... ...) (... 
...))) ((member type '("radio" "fuzzy" "custom-id" "coderef")) (let nil (if 
(run-hook-with-args-until-success 'org-open-link-functions path) nil (if (not 
arg) (org-mark-ring-push) (switch-to-buffer-other-window 
(org-link--buffer-for-internals))) (let ((destination (save-excursion ...))) 
(if (and (<= ... destination) (>= ... destination)) nil (widen)) (goto-char 
destination) (t (let nil (let ((f (org-link-get-parameter type :follow))) 
(if (functionp f) (progn (condition-case nil (funcall ... path arg) 
(wrong-number-of-arguments ...
  (let ((type (org-element-property :type link)) (path (org-element-property 
:path link))) (cond ((equal type '"file") (let nil (let* ((option 
(org-element-property :search-option link)) (path (if option ... path))) 
(org-link-open-as-file path (let* (...) (cond ... ... ...)) ((member type 
'("radio" "fuzzy" "custom-id" "coderef")) (let nil (if 
(run-hook-with-args-until-success 'org-open-link-functions path) nil (if (not 
arg) (org-mark-ring-push) (switch-to-buffer-other-window 
(org-link--buffer-for-internals))) (let ((destination ...)) (if (and ... ...) 
nil (widen)) (goto-char destination) (t (let nil (let ((f 
(org-link-get-parameter type :follow))) (if (functionp f) (progn 
(condition-case nil ... ...
  org-link-open((link (:type "file" :path "Figures/Ti19-g(w, eta={0.1,}, 
R=1e-3).svg" :format bracket :raw-link "file:Figures/Ti19-g(w, eta={0.1,}, 
R=1e-3).svg" :application nil :search-option nil :begin 1 :end 51 
:contents-begin nil :contents-end nil :post-blank 0 :parent (paragraph (:begin 
1 :end 103 :contents-begin 1 :contents-end 103 :post-blank 0 :post-affiliated 1 
:mode top-comment :granularity element :cached t :parent (section (:begin 1 
:end 103 :contents-begin 1 :contents-end 103 :robust-begin 1 :robust-end 101 
:post-blank 0 :post-affiliated 1 :mode first-section :granularity element 
:cached t :parent (org-data ...))) nil)
  (cond ((not type) (user-error "No link found")) ((memq type '(comment 
comment-block node-property keyword)) (call-interactively 
#'org-open-at-point-global)) ((memq type '(headline inlinetask)) 
(org-match-line org-complex-heading-regexp) (let ((tags-beg (match-beginning 
5)) (tags-end (match-end 5))) (if (and tags-beg (>= (point) tags-beg) (< 

Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)

[Ihor Radchenko]

Jim Porter  writes:

> On 2/5/2024 7:07 AM, Ihor Radchenko wrote:
>> It would make sense to add a number of alists:
>> - bounds-of-thing-at-point-provider-alist
>> - same for 'forward-op, 'beginning-op, 'end-op.
>> 
>> After Emacs have those, we can add Org mode support.
>
> That sounds reasonable enough to me; does anyone else have opinions on 
> this? Otherwise, I'll get to work on a patch (though probably not for a 
> couple weeks).

It has been a while since the last message in this thread.
Jim, may I know if you had a chance to work on the patch?

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

[Alexander Adolf]

Hello Ihor,

Many thanks for your swift response.

Ihor Radchenko  writes:

> [...]
>> Does anyone recall the rationale for this different behaviour?
>
> The "default" behaviour is to store summary of all the child property
> value in each parent.
> [...]
> This is, however, not possible for CLOCKSUM because clocksum is not an
> actual property, but a "special" one - it is derived from logbook data.
> That's why its behavior is different.

I see; thanks for explaining the rationale.

Practically this seems to imply that for doing estimates, and to
minimise my own confusion, I should probably use a strategy where I put
all the effort properties in a subtree at the same level (for instance
leaf-nodes-only, or top-nodes-only). And additionally, I should never
modify effort properties by hand, but using the columnview overlay only
(since that will not allow me to modify efforts computed from child
nodes).

> In fact, CLOCKSUM property does not support custom summaries.

???

>> Is there any way to change the summation behaviour for either or both
>> column types?
>
> It is currently hard-coded. (Although, it is not too hard add some kind
> of switch).
> [...]

I think that instead of a switch, I would prefer the columnview dblock
to get a :formatter added. Knowing how the values have been computed in
the dblock's write function, I can re-calculate whatever data I need in
the formatter.

I am already using this approach successfully with the clocktable dblock
to generate invoices for me.

Compared to a new switch, it would seem to me that adding a :formatter
to the columnview dblock has several advantages:

- it would likely be a smaller code change;

- instead of implementing a single, new behaviour (activated by switch)
  it would give users the flexibility to implement any new behaviour
  they might want (user-supplied :formatter function).


Thus, from my point of view, having a :formatter for the columnview
dblock would be quite fabulous. 濾


Cheers, and looking forward to your thoughts,

  --alexander

Re: Bug: inconsistent handling of empty duration cells in table [9.4.6 (9.4.6-12-gdcc3a8-elpa @ /home/jet/.config/emacs/elpa/org-20210816/)]

[Ihor Radchenko]

Jeff Trull  writes:

> When calc formulas producing empty strings are evaluated in the default
> mode, an empty cell is produced. When evaluated in duration mode (U, T,
> or t) a zero duration is produced. I feel the behavior should be
> consistent with the number formats, producing a empty value instead of a
> zero.

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

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

Re: Verbatim content (inline-special-block)

[Max Nikulin]

On 11/04/2024 19:58, Ihor Radchenko wrote:

Max Nikulin writes:

   @code{ unlike =code=, we can have leading and trailing spaces }
   @code{ @foo{is not interpreted inside}}


I think, it should be controlled by some optional parameter like

  @kbd[:verbatim t]{ unlike =code=, ... }


I do not like this idea - this will make the attribute list a part of
the Org markup spec,


I see you point and I agree that it is valid concern. On the other hand 
I do not have strong opinion what variant is better.



It may be enough to have @kbd{@code{...}} - it is not like Texinfo has a
concept of truly verbatim text like in Org.

Alternatively, we may allow two classes of inline markup:
@foo{parsed *text* inside}
and
@foo={verbatim *text* inside}/@foo~{verbatim *text* inside}

This way, instead of @code{}, we should use @code~{...} or even
@~{...}/@={...} (mnemonics for ~...~ and =...=)


I consider @foo={}-like variants as unnecessary complications of the 
inline special block feature. The idea of composition is better from my 
point of view. With this approach it is enough to have non-conflicting 
syntax for non-parsed fragments. I am against making @code{} a special 
name with suppressed markup parsing. The price of composition in 
comparison with @foo={} is more verbose markup.


By the way, Org has src_lang{...} syntax for almost non-parsed fragments 
(neglecting requirement of balanced curly brackets that is an issue).


Actually "=" in @foo={} is a kind of special argument distinct from ones 
specified inside [] and {}.



  @code{def calculate(@param{expr}, @param{env})}

[...]

Also, the reason why Texinfo users do @param in @code is the lack of
automatic syntax highlighting, unlike in Org mode.


Is ox-texinfo able to convert syntax highlighting to native texinfo markup?

So if @markup{} is not allowed in verbatim content then it is another 
feature loosely related to custom inline blocks.

Re: [PATCH] Ensure org-table-header displays without cursor inside table

[Bastien Guerry]

Ihor Radchenko  writes:

> P.S. Bastien, may your please check Lei Zhe's copyright status?

Yes, I confirm Lei Zhe copyright status is okay.

-- 
 Bastien Guerry

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: Wed, 10 Apr 2024 14:31:22 +
>
> Protesilaos Stavrou  writes:
>
>> 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.
>>
>> What do you think?
>
> That may work. One may simply change the anchors for footnote references
> and footnotes when they are labeled. However, we should be careful when
> labels are duplicated (multiple references to the same named footnote) -
> only a single back-reference is possible from the footnote definition
> back to footnote reference.

I think the issue of labelling the footnotes is separate from
disambiguating them and avoiding duplicates. Of course, having the
latter is nice. But the part about the labels should be limited to the
use of the data we already have to keep the patch/change small (maybe
subject to an opt-in user option to not disrupt any existing workflow).

With regard to the disambiguation scheme, I am playing around with
various scenaria to see how Org HTML export behaves. Using the
following:

* Heading

This is test 1 [fn:hello]
This is test 2 [fn:hello]
This is another test [fn:1]
This is test 3 [fn:hello]

* Footnotes

[fn:1]
[fn:hello] Hello 

We get this excerpt from the HTML output:

This is test 1 1
This is test 2 1
This is another test 2
This is test 3 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?

-- 
Protesilaos Stavrou
https://protesilaos.com