emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Jean Louis <bugs@gnu.support>
To: Samuel Wales <samologist@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Custom <<anchor>> possibility?
Date: Fri, 21 May 2021 02:00:31 +0300	[thread overview]
Message-ID: <YKbqDzmkEef6yLZm@protected.localdomain> (raw)
In-Reply-To: <CAJcAo8uXh+g+=T4RVPTEuCXsq6rv+Jfqs8rqz8JfpCsXfrJn+Q@mail.gmail.com>

* Samuel Wales <samologist@gmail.com> [2021-05-21 01:19]:
> thanks for pointing us to this variable.
> 
> docstring says "This process ensures that these values are unique and
> valid...", so it sounds like you could create non-unique or invalid
> identifiers without it.
> 
> does this mean, for example, if the user exports a subtree with two
> link targets with the same user label, then if this variable is
> non-nil, then the output could include more than one link target?

I may try to give the example here:

<<paragraph>>
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec a diam
lectus. Sed sit amet ipsum mauris. 

<<paragraph>>
Vivamus fermentum semper porta. Nunc diam velit, adipiscing ut
tristique vitae, sagittis vel odio. Maecenas convallis ullamcorper
ultricies.

which results in:

<a id="paragraph"></a>
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec a diam
lectus. Sed sit amet ipsum mauris. 
</p>

<p>
<a id="paragraph"></a>
Vivamus fermentum semper porta. Nunc diam velit, adipiscing ut
tristique vitae, sagittis vel odio. Maecenas convallis ullamcorper
ultricies.
</p>

> what if this var were nil [the default], my brain is not working well
> now, but it seems as if the exporter could still get confused which
> target to link to, even if it is not printing duplicatedly-named
> targets.
> 
> so i am curious what the purpose of the default is?

You already discovered the purpose: "This process ensures that these
values are unique and valid..."

Randomly generated internal hyperlinks are not part of author's
document creation and I don't believe they can be unique across all
documents as they rely on randomity, not uniqueness, but they may be
unique in one document. The sentence should say "This process ensures
that these values are unique to specific document and valid"

Problem with it is that those random anchors/links are random, and
that makes it a bad default for user. A user may bookmark the link 

https://www.example.com/doc#org2cf8625 with some title, but with the
next document generation same link may appear as
https://www.example.com/doc#org6ac9de0 and that means that bookmark
disappeared, at least for HTML export.

For me personally I am editing Org text (not files) on a meta level
where all objects have its unique ID and from there I can create Org
files. Then each object of a structure of meta level Org has its
unique ID. Also the document has its unique ID. Then it becomes
possible to automatically create anchors like <<1:17311:31121>> which
are truly unique across all documents, remain immutable, and are
trackable. With "trackable" I mean that it is possible to generate a
list of "referenced by" documents, documents which hyperlink to that
anchor.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://stallmansupport.org/
https://rms-support-letter.github.io/



  reply	other threads:[~2021-05-20 23:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-20 19:25 Custom <<anchor>> possibility? Jean Louis
2021-05-20 19:59 ` Nicolas Goaziou
2021-05-20 20:19   ` Jean Louis
2021-05-20 22:18     ` Samuel Wales
2021-05-20 23:00       ` Jean Louis [this message]
2021-05-20 23:50         ` Samuel Wales
2021-05-21 12:51       ` Nicolas Goaziou
2021-05-21 19:28         ` Samuel Wales

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=YKbqDzmkEef6yLZm@protected.localdomain \
    --to=bugs@gnu.support \
    --cc=emacs-orgmode@gnu.org \
    --cc=samologist@gmail.com \
    /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).