From: chris <inkbottle007@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Internal link broken when publishing (was org-id with ox-html)
Date: Mon, 20 Sep 2021 02:05:57 +0200 [thread overview]
Message-ID: <51009862.OmzxVWrqTf@pluto> (raw)
In-Reply-To: <shqit9$8ds$1@ciao.gmane.io>
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.
next prev parent reply other threads:[~2021-09-20 0:06 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
2021-09-20 0:05 ` chris [this message]
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
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=51009862.OmzxVWrqTf@pluto \
--to=inkbottle007@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
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).