Re: stability of toc links

[Maxim Nikulin]

On 21/04/2021 23:24, Nicolas Goaziou wrote:
> In particular, I'm not sure to understand how one system can generate an
> ID based on the heading content and still limit itself to alphanumeric
> characters. For example, what ID are generated with the following
> document?

My impression is that such conversion is rather wide spread in various 
web CMS and documentation generators. I strongly prefer human-readable 
anchors (when I can guess link content and realize if I have read it 
earlier)

https://werkzeug.palletsprojects.com/en/1.0.x/tutorial/#step-0-a-basic-wsgi-introduction

to codes like

https://orgmode.org/worg/org-hacks.html#org98f055b

I know, Cyrillic is a trivial case in comparison to your example below, 
however that is the case when I can confirm that result of 
transliteration to ASCII is usually readable enough. It is usually 
applied to article title to generate a path component of URL.

> --8<---------------cut here---------------start------------->8---
> * こんにちは
> * ｺﾝﾆﾁﾊ
> --8<---------------cut here---------------end--------------->8---

Sorry, I can not estimate if the following conversion is accurate enough:

python3 -c 'import unidecode; print(unidecode.unidecode("こんにちは"))'
konnichiha

python3 -c 'import unidecode; print(unidecode.unidecode("ｺﾝﾆﾁﾊ"))'
konnitiha

Hex anchors could be a fallback if smarter method could not generate 
something reasonable. Finally, exporters can generate compiler-like 
warnings if some problem with anchor stability/ambiguity is detected. A 
helper function may be suitable to fix ID before editing of a heading.

Actually it was not obvious to me that IDs like org98f055b may be 
stable. It is a hidden feature. I do not know if Samuel can adjust his 
workflow to use copy from "published" (to local directory) files instead 
of copy from export buffer. I guess, as a starting point it is necessary 
to pre-populate cache with IDs from existing HTML documents somehow.

Anyway thank you for clarifying of the role of publishing.