From: Tim Cross <email@example.com> To: Nicolas Goaziou <firstname.lastname@example.org> Cc: email@example.com, Samuel Loury <firstname.lastname@example.org> Subject: Re: stability of toc links Date: Sat, 01 May 2021 07:12:34 +1000 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> Nicolas Goaziou <email@example.com> writes: > Hello, > > Samuel Loury <firstname.lastname@example.org> writes: > >> The publish feature only means exporting several files at once. > > You can publish a single file, too. It makes sense when a file is always > exported to the same location, possibly with the same configuration. > >> IIUC, what was written was that when using the publish feature, the exported >> html pages will be coherent and a link in one document pointing to >> another document of the same publish call won't be broken. >> >> But IIUC, publishing the whole stuff again will result in totally >> different links. They will still be coherent and no broken link from one >> document of the whole to another. But a browser bookmark pointing the >> published lot the first time won't work with the same lot the second >> time. >> >> Did I understand correctly? > > That's correct. > > Org provides a mechanism, called `org-export-get-reference', for > creating internal references, which relies on randomness + cache. But it > explicitly removes internal references not actually used from there (see > `org-publish--store-crossrefs'). Keeping those references instead would > make all links stable, of course. > Given this is not the first time we have seen a similar discussion regarding link stability for external references, perhaps it would be good to summarise and put it on worg for reference? First attempt - let me know if I've got it close! - If you need stability in TOC links between generated versions, use Org's publish facility rather than plain HTML export. - Publish can be used to publish a single file. - 'something' in the published output needs to reference the TOC links to ensure consistency. HTML export lacks the internal caching/tracking necessary to have internal link consistency across exported versions. Adding such capability would significantly complicate the HTML export code base. This is hard to justify when this export facility is also used for things like HTML fragments and because internal link stability is only required in a sub-set of use cases. The org publish facility already includes the necessary internal facilities to support internal link consistency across published versions. You can use publish to publish a single file. Currently, the internal links need to be referenced/used in order to ensure consistency across published versions. If stability of TOC links across versions is required, using publish is the preferred mechanism. If we would want to make it easier for the user to create published pages with consistent internal TOC links, we would be better off enhancing the publish mechanism rather than trying to add such facilities to the HTML export function. -- Tim Cross
next prev parent reply other threads:[~2021-04-30 21:52 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-12-08 23:28 Samuel Wales 2020-12-08 23:30 ` Samuel Wales 2020-12-09 1:39 ` Tom Gillespie 2020-12-12 21:51 ` TRS-80 2020-12-12 22:47 ` TRS-80 2020-12-09 2:48 ` TEC 2020-12-09 8:45 ` Diego Zamboni 2020-12-09 9:15 ` Carsten Dominik 2020-12-09 21:25 ` Samuel Wales 2020-12-10 9:55 ` Carsten Dominik 2020-12-10 12:49 ` TEC 2020-12-10 14:36 ` TEC 2020-12-11 7:51 ` Carsten Dominik 2020-12-19 6:41 ` Carsten Dominik 2020-12-19 11:22 ` Ihor Radchenko 2021-04-18 21:02 ` Samuel Wales 2020-12-14 10:46 ` Dominique Dumont 2021-04-18 10:32 ` Nicolas Goaziou 2021-04-20 0:58 ` Samuel Wales 2021-04-20 10:34 ` Nicolas Goaziou 2021-04-21 0:33 ` Samuel Wales 2021-04-21 8:32 ` Nicolas Goaziou 2021-04-21 13:32 ` Samuel Loury 2021-04-21 16:24 ` Nicolas Goaziou 2021-04-23 15:15 ` Maxim Nikulin 2021-04-23 20:46 ` Samuel Wales 2021-04-23 20:48 ` Samuel Wales 2021-04-23 20:51 ` Samuel Wales 2021-04-24 3:05 ` Timothy 2021-04-25 17:01 ` Dominique Dumont 2021-04-30 6:24 ` Timothy 2021-04-30 12:20 ` Maxim Nikulin 2021-04-21 23:20 ` Samuel Wales 2021-04-21 23:30 ` Samuel Wales 2021-04-29 21:40 ` TRS-80 2021-04-29 22:18 ` Samuel Wales 2021-04-30 1:48 ` TRS-80 2021-04-30 5:13 ` Tim Cross 2021-04-30 10:02 ` Samuel Loury 2021-04-30 11:12 ` Nicolas Goaziou 2021-04-30 21:12 ` Tim Cross [this message] 2021-05-01 12:36 ` Nicolas Goaziou 2021-05-01 12:48 ` Timothy 2021-05-01 13:13 ` Nicolas Goaziou 2021-05-01 13:47 ` Timothy 2021-05-01 14:09 ` Nicolas Goaziou 2021-05-01 14:22 ` Timothy 2021-05-02 12:10 ` Nicolas Goaziou 2021-05-02 20:16 ` Timothy 2021-05-01 3:08 ` Greg Minshall
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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: stability of toc links' \ /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
Code repositories for project(s) associated with this 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).