As a kind of summary:
During publishing of a project
- "id:" links to headings from the same file are exported as short
generated anchors like #org032777e or as anchors to custom ids when the
latter are available
- "Search heading" links to other files are exported as short generated
anchors or as custom ids.
- "id:" links to headings in external files are exported as ID value
with "ID-" prefix. These links are *broken* currently.
Expected behavior is the same style of anchors for particular heading, e.g.
- value of custom_id property is used even for "id:" links
- either value of id property or short generated anchor is used for
links to a heading having id property (maybe it should be possible to
customize preferred style) but the same for search heading text fuzzy
links and "id:" links, internal and external ones.
I do not mind to have both anchors with value of id and custom_id
properties if they are defined for a header.
My opinion is that value of id property should be used for heading
anchor when available to guarantee stable links from other sites. I
admit that default behavior may be short (perhaps unstable) anchors.
On 07/09/2021 22:46, chris wrote:
On Tuesday, 24 August 2021 17:23:24 CEST Maxim Nikulin wrote:
On 23/08/2021 03:42, inkbottle wrote:
From my point of view it looks like a bug.
https://code.orgmode.org/bzg/org-mode/src/master/lisp/ox.el#L4381
...
I believe it's a bug, plain and simple.
I am afraid that its fix would not be so simple.
With a unique org file, the `:ID: e54113f9-2ad7-4a86-94be-68ffc696de0b` are
resolved to `orgfa9c151` consistently.
My opinion (in contradiction to Nicolas) is that anchors should be as
stable as possible even in the absence of cross-references withing the
document. It allows links from other sites to particular sections. That
is why value of ID property is better than random anchor despite the
former is longer.
There is a patch here:
https://gist.github.com/jethrokuan/d6f80caaec7f49dedffac7c4fe41d132
but, as I understand it, the workaround consists in treating `:ID:` similarly
as `:CUSTOM_ID:`, that is, exporting them "verbatim".
If it were a patch, it would be easier to spot the changed part. This
approach may be implemented in a bit cleaner way but I do not think that
it will allow to use custom_id value for "id:" link if a heading has
both (see `org-html-link' and `org-export-resolve-id-link').
checks for ID property.
https://code.orgmode.org/bzg/org-mode/src/master/lisp/ox-html.el#L1659
queries CUSTOM_ID only. I suppose, ID should be here as well. A subtle
point is which one (ID or CUSTOM_ID) should be used if both are defined
for some headers.
Yes, "ID should be here as well" => No.
That is the point I'm advocating above.
`:CUSTOM_ID:` are meant to be treated in a so-called "stable" way. That is to
say, the `CUSTOM_ID` you see in your org-file, is what you get in your HTML file
(also I've done some tests with that method, and I recall it wasn't working at
all in a multiple org files setting).
On the other hand, `:ID:` are meant to be treated through a *translation
table*, and should result in some `orgfa9c151` thing, on the HTML side.
Weaving the two methods together doesn't seem like "road to success".
In a general case it is rather hard to get stable anchors, even having
full history of changes. On the other hand I see no reason to avoid
stable IDs where they exist. Looks like a reason for defcustom at least.
I consider random anchors and the cache to make some of them stable as
an unavoidable fallback when there is no better way (users avoid
property drawers).
Maybe it is possible to create workaround as a custom config without
touching of Org code. I guess, "nicer" ids may be replaced by values of
ID property. Examples (I tried none of them):
-
https://tecosaur.github.io/emacs-config/config.html#nicer-generated-heading
https://orgmode.org/list/e1jxajq-0004dk...@lists.gnu.org/ (TEC.
[Interest] Determanistic Org IDs. Sun, 19 Jul 2020 22:27:31 +0800)
...
The methods above are, as I understand it, all about making more beautiful
links to export to HTML.
Not about the "translation table" devised in `ox.el` being broken when working
with multiple org-files.
My idea of a workaround was to throw away all code deriving pretty link
and to put ID value instead.