emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Samuel Wales <samologist@gmail.com>
To: Samuel Loury <konubinix@gmail.com>
Cc: emacs-orgmode@gnu.org, Nicolas Goaziou <mail@nicolasgoaziou.fr>
Subject: Re: stability of toc links
Date: Wed, 21 Apr 2021 16:30:41 -0700	[thread overview]
Message-ID: <CAJcAo8s_R-eYyZLjwHC88_t4Pf+djQGv0pQ+GAuxPtUTO_4JJg@mail.gmail.com> (raw)
In-Reply-To: <CAJcAo8tz1++=ZR9e6j0VCKqK3+-EBzSCBoJ3nujja8jzHuZ4Aw@mail.gmail.com>

as it has been a long time my original post is

Message ID	<CAJcAo8tXVW39h18FUXLtwoDYNKQsFHqCp+YDiyWfLee29B1PRw@mail.gmail.com>

and the content is

===
when you link to a section using toc, you get a link like

  https://thekafkapandemic.blogspot.com/2020/02/crimes-against-humanity_3.html#org080f0ab

will these links break if somebody copies them and pastes them
elsewhere?  what if you add a section?

there doesn't seem to be a perfect solution, short of adding custom id
or id to everything, but perhaps a fuzzy hash of the header and
contents of the section could be used?  or a strict hash of the
header?  is anything like this being done?  just curious.
===

On 4/21/21, Samuel Wales <samologist@gmail.com> wrote:
> more below.  [note the two samuels.]
>
> On 4/21/21, Samuel Loury <konubinix@gmail.com> wrote:
>> advance what heading he will share, so he would have to add CUSTOM_ID
>> everywhere, just in case. This sounds like a lot of unnecessary work.
>>
>> The solution of tec¹ appears to be a new generation of the html ids based
>> on the heading content rather than apparently randomly generated, making
>> the generated link become the same across new generations.
>>
>> I hope it clarified the discussion.
>
> it did improve it.  thank you.  the above is concise and clear.
>
> suppose reader A wants to send a link to reader B.
>
> one exported [i did not use org's publish facility] post is
> https://thekafkapandemic.blogspot.com/2020/02/crimes-against-humanity_3.html
> .  it has MANY sections.  i turn off toc for a whole section and then
> put a toc in that section just to make the main toc less forbidding.
> here is the html for just the top few entries of the main toc --
> notice 3 links each with a hex code that changes.
>
> <div id="table-of-contents">
> <h2>Table of Contents</h2>
> <div id="text-table-of-contents">
> <ul>
> <li><a href="#org360b8b5">This post</a></li>
> <li><a href="#orgdff6ff2">The name of the law</a></li>
> <li><a href="#orgeb015f7">Basic facts</a></li>
>
> suppose i add a section after This post.  Most links will now be
> broken.  A could have sent any of them to B as raw hex links.
>
> i just want the problem understood at the user level.  i get that
> there are possible implementation issues.
>
> i spent 16 years researching and writing the blog post.  i don't want
> links to be broken or to have to kludge in a bunch of custom id or org
> id properties drawers just in case somebody links.  even if drawers
> are added to every linked section automatically, it's a lot of clutter
> and slowness [org id searches are slow and drawers have performance
> issues that are being worked on but not merged into maint yet].  that
> is a lot of drawers just for links that might or might not be sent.
>
> i am limited in computer use so i will probably not pursue this
> further if there is no interest.
>
> there is some interest.  e.g. carsten said he thought tec's code or
> somethign like it should be merged into org qua org.
>
> --
> The Kafka Pandemic
>
> Please learn what misopathy is.
> https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
>


-- 
The Kafka Pandemic

Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html


  reply	other threads:[~2021-04-21 23:31 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 [this message]
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
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 \
    --in-reply-to=CAJcAo8s_R-eYyZLjwHC88_t4Pf+djQGv0pQ+GAuxPtUTO_4JJg@mail.gmail.com \
    --to=samologist@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=konubinix@gmail.com \
    --cc=mail@nicolasgoaziou.fr \
    /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).