emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Tim Cross <theophilusx@gmail.com>
Cc: emacs-orgmode@gnu.org, Timothy <tecosaur@gmail.com>
Subject: Re: HTML export uses anchor ids which change on every export
Date: Sun, 30 May 2021 14:11:13 +0200	[thread overview]
Message-ID: <87czt8xvz2.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <87r1ho8z6f.fsf@gmail.com> (Tim Cross's message of "Sun, 30 May 2021 16:56:22 +1000")


Tim Cross <theophilusx@gmail.com> writes:

> Perhaps I misunderstood. My reading was that none of the proposed
> approaches were complete enough (in the sense they either introduced
> other issues or, while addressing some corner cases, made it much harder
> to address others, broke or failed to cater for other workflows).
> I was left with the general impression that solving this issue required
> a significant amount of re-development and a far more sophisticated
> approach for tracking, caching/memoizing IDs and attempting to address
> the issues just by patching the existing code was only going to make
> small improvements while complicating the existing code and making it
> harder to maintain. In short, a significant re-design and
> re-implementation effort rather than application of patches on the
> existing code base is required and until someone can do this work, the
> best approach was to use publish instead of export if link stability was
> required.

I agree on some points, but my analysis is slightly different. In
particular, it seems to me the whole topic is conflating problems. And
the mistake is to look for a single solution that solves them all.

First, _external_ link stability is a solved problem. Users need to use
CUSTOM_ID, no matter what they think about it. I do believe there is no
other automatic way to solve this. Only approximations of a solution,
which will bite you in one way or the other, as you noted.

Secondly, _internal_ link stability is not that important. By
definition, if you're not going to see them, you don't care about what
they look like, as long as they correctly link the expected parts of the
document. Current implementation of internal references guarantees all
internal links do work, with export or publish, but does not go further.
I don't think we need another solution for internal links since they do
the job.

This is not to say there is no problem to solve, of course. Currently,
internal links sometimes leak outside, which understandably bothers
users. Even though there is no ultimate solution for this besides
manually writing every link going to the outside, it may be possible to
mitigate the issue, if users accept to get bitten from time to time.

With that in mind, I think Timothy's solution goes in the right
direction, but, IMO, attempts to solve the problem at the wrong level,
i.e., by trying to unify all links (internal and external) into a single
banner. I'm not convinced this is doable, because expectations are so

However, this kind of solution could be implemented in Org and used by
export back-ends generating external links. For example, Org Export
could provide, e.g., `org-export-punycode', and Org Export HTML could
use instead of internal `org-export-get-reference'. As I wrote already,
Org Export Texinfo does something similar for the nodes it generates.
Since those are meant to be external references, the back-end tries hard
to generate something meaningful (in `org-texinfo--get-node') and, as
a last resort, `org-export-get-reference'. Even though I mentioned it in
the other thread, it didn't attract much interest.

This is, I think, a practical way to improve the actual problem, i.e.,
how to to generate automatically pseudo-stable external links (note: I'm
writing this without contempt).

Nicolas Goaziou

  reply	other threads:[~2021-05-30 12:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-29 18:18 HTML export uses anchor ids which change on every export sbaugh
2021-05-29 19:50 ` Nicolas Goaziou
2021-05-29 19:54   ` Timothy
2021-05-29 23:10     ` Tim Cross
2021-05-30  5:16       ` Timothy
2021-05-30  6:56         ` Tim Cross
2021-05-30 12:11           ` Nicolas Goaziou [this message]
2021-06-08 23:31   ` Spencer Baugh
2021-06-09 12:19     ` Nicolas Goaziou

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=87czt8xvz2.fsf@nicolasgoaziou.fr \
    --to=mail@nicolasgoaziou.fr \
    --cc=emacs-orgmode@gnu.org \
    --cc=tecosaur@gmail.com \
    --cc=theophilusx@gmail.com \


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