Re: Internal link broken when publishing (was org-id with ox-html)

[Max Nikulin <manikulin@gmail.com>]

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