From: Max Nikulin <firstname.lastname@example.org>
Subject: Re: Internal link broken when publishing (was org-id with ox-html)
Date: Tue, 14 Sep 2021 23:33:43 +0700 [thread overview]
Message-ID: <email@example.com> (raw)
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.
> 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:
> 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.
>> 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
>> 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://orgmode.org/list/E1jxAjq-0004Dk-LH@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.
next prev parent reply other threads:[~2021-09-14 16:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-13 22:28 org-id with ox-html inkbottle
2021-08-14 0:50 ` inkbottle
2021-08-14 4:20 ` inkbottle
2021-08-17 3:11 ` Internal link broken when publishing (was org-id with ox-html) inkbottle
2021-08-22 20:42 ` inkbottle
2021-08-24 15:23 ` Maxim Nikulin
2021-09-07 15:46 ` chris
2021-09-14 16:33 ` Max Nikulin [this message]
2021-09-20 0:05 ` chris
2021-09-20 14:13 ` Max Nikulin
2021-09-20 15:26 ` chris
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).