From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: stability of toc links
Date: Fri, 30 Apr 2021 15:13:15 +1000 [thread overview]
Message-ID: <87h7joibxc.fsf@gmail.com> (raw)
In-Reply-To: <CAJcAo8vGX3K_J+b41X1f+jERqLSiGzVdznBwvGornDDRVcSSmA@mail.gmail.com>
Samuel Wales <samologist@gmail.com> 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: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-08 23:28 stability of toc links 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
2022-10-10 0:49 ` Samuel Wales
2022-10-10 1:37 ` Samuel Wales
2022-10-11 3:12 ` Robert Weiner
2022-10-11 11:25 ` Ihor Radchenko
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
2022-10-11 11:44 ` [FR] [Revived] Human readable / customizable link anchors during export (was: stability of toc links) Ihor Radchenko
2022-10-11 19:20 ` [FR] [Revived] Human readable / customizable link anchors during export Kévin Le Gouguec
2022-10-12 6:33 ` Ihor Radchenko
2022-10-12 17:38 ` Kévin Le Gouguec
2021-05-01 3:08 ` stability of toc links 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 \
--in-reply-to=87h7joibxc.fsf@gmail.com \
--to=theophilusx@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).