emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Max Nikulin <manikulin@gmail.com>
To: emacs-orgmode@gnu.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: <shqit9$8ds$1@ciao.gmane.io> (raw)
In-Reply-To: <4827285.5yCLvEFndJ@pluto>

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.

  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

Reply instructions:

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 \
    --in-reply-to='shqit9$8ds$1@ciao.gmane.io' \
    --to=manikulin@gmail.com \
    --cc=emacs-orgmode@gnu.org \


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