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

[chris <inkbottle007@gmail.com>]

On Tuesday, 14 September 2021 18:33:43 CEST Max Nikulin wrote:
> 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.

Thanks a lot.
Perfectly functional org-id links between two files are broken when published 
to HTML.
I suppose a bug should be opened about that?
(I can do that in a few weeks.)

CUSTOM_ID solution is not good because you have to specify what file the ID is 
in. With plain ID, you specifically do not have to specify in which file the ID 
is, and therefore you can freely move around entries with ID, even beyond the 
file boundary, without troubling yourself. Because there is some sort of 
database behind, taking care of it for you.

For the exporting, considering the "ID-db" must be queried, and a translation 
process must be applied, I don't think there should be any specifications about 
the way it is implemented.

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