emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Samuel Wales <samologist@gmail.com>
To: Samuel Wales <samologist@gmail.com>, emacs-orgmode@gnu.org
Subject: Re: Custom <<anchor>> possibility?
Date: Thu, 20 May 2021 16:50:11 -0700	[thread overview]
Message-ID: <CAJcAo8voc+1fuE2YKVdm0JvQD_eYAS9PQJh1+Z8NKCDkEmQ9vA@mail.gmail.com> (raw)
In-Reply-To: <YKbqDzmkEef6yLZm@protected.localdomain>

thanks for the example.  yes, that is the example i was thinkng of.

i was asking, why does adding uniqueness do any good currently.  if
the user has your example as follows, it does create duplicates in the
output, but i don't get why that all by itself needs fixing by
default.

===vvv
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>
===^^^

so the duplicates in the output there are apparently a problem.  i am
not sure why, unless a link needs to point to each.  perhaps so that
the reader of the web page can point to each?  but as you say,
generating the document again foils that plot.

[note: i started the thread about toc links.  this is a subtly
different question although it overlaps.]


On 5/20/21, Jean Louis <bugs@gnu.support> wrote:
> * 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/
>
>


-- 
The Kafka Pandemic

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


  reply	other threads:[~2021-05-20 23:50 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
2021-05-20 23:50         ` Samuel Wales [this message]
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=CAJcAo8voc+1fuE2YKVdm0JvQD_eYAS9PQJh1+Z8NKCDkEmQ9vA@mail.gmail.com \
    --to=samologist@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).