Hello,
Jorge P. de Morais Neto writes:
> But could not we URL-encode the dedicated target text?
My example was about HTML, but the same process is used in every export
back-end. URL-encoded strings may also be invalid in other back-ends.
> In my testing, Org generates an ugly anchor even if
Hello,
Em 2019-08-18T12:40:29+0200, Nicolas Goaziou escreveu:
> That's because the text could contain anything, including invalid HTML
> characters. So we normalize them using only alphanum characters.
But could not we URL-encode the dedicated target text? In my testing,
Org generates an ugly
Hello,
Jorge P. de Morais Neto writes:
> But why does Org not use the dedicated target text as an anchor?
That's because the text could contain anything, including invalid HTML
characters. So we normalize them using only alphanum characters.
Regards,
--
Nicolas Goaziou
Hello,
Em 2019-07-28T10:10:01+0200, Nicolas Goaziou escreveu:
> Custom ID are user-defined, and only meaningful in the scope of the
> document. Also, they may appear as-is when exported, e.g., as an anchor
> in HTML.
>
> ID are (or should be) generated by Org, and are valid across files,
> which
Nathan Neff writes:
> * Show the IDs (*and* headings :-) of recently created links (because you
> know,
> the IDs are hash codes (grumble grumble). Currently Helm just shows the IDs
> :-(
Small pedantry: they're UUIDs, not hashes. The distinction is
important, because UUIDs are generated
Nathan Neff writes:
> I have a lot of org files and one of the main purposes of links is to be able
> to link
> to different headings across documents. This seems to imply I should use
> the ID property.
>
> However, I usually *do* manually assign IDs (not CUSTOM_IDs) myself. The
> reason
On Sun, Jul 28, 2019 at 3:10 AM Nicolas Goaziou
wrote:
> Hello,
>
> Nathan Neff writes:
>
> > I've often been confused why org-mode has both a CUSTOM_ID
> > and a ID property. I mean, why not just use one or the other name?
>
> Custom ID are user-defined, and only meaningful in the scope of
Nicolas Goaziou writes:
> David Masterson writes:
>
>> Can you talk a little bit about how IDs are generated so that they are
>> absolutely unique?
>
> See `org-id-new'. By default, it uses "uuidgen" command.
>
>> IDs sound like something that would be useful for synchronizing
>> information
Hi Nate,
Nathan Neff writes:
> However, I usually *do* manually assign IDs (not CUSTOM_IDs) myself.
> The reason is so I can reasonably search for the ID within my org
> files and that the link ID makes some sense to me.
>
> For example, if I see a link to "id:keyboard_shortcuts" I can tell
On Sun, Jul 28, 2019 at 3:10 AM Nicolas Goaziou
wrote:
> Hello,
>
> Nathan Neff writes:
>
> > I've often been confused why org-mode has both a CUSTOM_ID
> > and a ID property. I mean, why not just use one or the other name?
>
> Custom ID are user-defined, and only meaningful in the scope of
Hello,
David Masterson writes:
> Can you talk a little bit about how IDs are generated so that they are
> absolutely unique?
See `org-id-new'. By default, it uses "uuidgen" command.
> IDs sound like something that would be useful for synchronizing
> information between two (or more) separate
Nicolas Goaziou writes:
> Nathan Neff writes:
>
>> I've often been confused why org-mode has both a CUSTOM_ID
>> and a ID property. I mean, why not just use one or the other name?
>
> Custom ID are user-defined, and only meaningful in the scope of the
> document. Also, they may appear as-is
Hello,
Nathan Neff writes:
> I've often been confused why org-mode has both a CUSTOM_ID
> and a ID property. I mean, why not just use one or the other name?
Custom ID are user-defined, and only meaningful in the scope of the
document. Also, they may appear as-is when exported, e.g., as an
13 matches
Mail list logo