emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Samuel Wales <samologist@gmail.com>
To: TRS-80 <lists.trs-80@isnotmyreal.name>
Cc: emacs-orgmode@gnu.org
Subject: Re: stability of toc links
Date: Thu, 29 Apr 2021 15:18:24 -0700	[thread overview]
Message-ID: <CAJcAo8vGX3K_J+b41X1f+jERqLSiGzVdznBwvGornDDRVcSSmA@mail.gmail.com> (raw)
In-Reply-To: <33fd87ff1332b56114909973804df669@isnotmyreal.name>

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.


On 4/29/21, TRS-80 <lists.trs-80@isnotmyreal.name> wrote:
> On 2021-04-21 19:30, Samuel Wales wrote:
>> 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.
>
> My "quick and dirty" solution was to make a function to map over each
> heading and assign a custom ID based on the text of the heading.  It
> only assigned one if one did not exist already (so in case you had
> done any manual adjustments they would not be overwritten).
>
> I had posted it very early in the thread, but it did not seem to gain
> much interest.  It was not posted as a "long term and proper solution
> to be included into Orgmode" but rather a quick and easy workaround in
> the meantime.
>
> Cheers,
> TRS-80
>
>


-- 
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-29 22:19 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 [this message]
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=CAJcAo8vGX3K_J+b41X1f+jERqLSiGzVdznBwvGornDDRVcSSmA@mail.gmail.com \
    --to=samologist@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=lists.trs-80@isnotmyreal.name \
    --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).