From: Tim Cross <email@example.com> To: firstname.lastname@example.org Subject: Re: stability of toc links Date: Fri, 30 Apr 2021 15:13:15 +1000 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <CAJcAo8vGX3K_J+b41X1f+jERqLSiGzVdznBwvGornDDRVcSSmA@mail.gmail.com> Samuel Wales <firstname.lastname@example.org> writes: > hi trs, > > thank you. i can imagine that could be useful for a lot of users, but > for me, as i said in my op, "short of adding custom id > or id to everything" --- i didn't want to add custom id. i will try > to clarify why in case it is useful. > > in addition to performance, and clutter, there is a semantic issue in > my case. typically, if i see that there is a properties drawer, i > know that it is there because of an org id or a manual custom id or a > special purpose of my own. if i know it, i don't need to open it. > > however, adding custom id automatically for so many links means that > there is a new meaning for properties drawers [namely, for stable > linking done automatically]. i would have to open the drawer to > determine if i personally wanted something there. > > and thus, the extra properties drawers would cause effort and > distraction in this semantic sense, where i would be opening them > because i would be thinking "did i really have a reason to add a > properties drawer here? i don't recall so... better check" > > also, there is the issue that if i decide not to include something in > the toc, it will still have a properties drawer lying around. > > > in the op, i was not looking for a solution for one blog post, but > thought a general solution for all org users might be possible. > > and this would likely be at the html level, probably by using e.g. > header text, fuzzy or strict hashes, or a combination. > > when tec posted his html level code, it looked like the right type of > solution to the problem. i have not tried it, however. > > i hope that clarifies. tec said he originally did not get much > interest. then there was interest on this thread. then nothing. > A question to help me understand this issue. If I understand correctly, exporting to HTML does not guarantee stability of TOC links. If you export as HTML, send someone a link from the toc and then re-export the document, the link will possibly be broken. Essentially, exporting to HTML has no guarantee of stability in toc links. However, if you use publish instead of exporting to HTML, there is a guarantee of stability in toc links. When publishing a second time, the link will be consistent and still valid. If you want stability in toc links, why not use publish instead of export to html? Is there some difference between the two mechanisms which prevents you from being able to use publish instead to get stable links?
next prev parent reply other threads:[~2021-04-30 5:23 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 [this message] 2021-04-30 10:02 ` Samuel Loury 2021-04-30 11:12 ` Nicolas Goaziou 2021-04-30 21:12 ` Tim Cross 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 \ --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).