Oh, that's great news! Will be very useful; thanks Ihor!
Unfortunately life has come in the way so I haven't had the chance to pursue
this further at the moment.
All the best,
Tor
On Wed, 06/03/2024, Ihor Radchenko wrote:
> Tor Erlend Fjelde writes:
>
>>> As an alternative option, we had a p
Tor Erlend Fjelde writes:
>> As an alternative option, we had a proposal that extends id: links to
>> have a search option:
>>
>> [[id:::search-string]]
> ...
> Indeed; I was actually about to have a go at implementing this because
> I thought this would be the quickest way of adding support for
Max Nikulin writes:
>> If we simply allow id: links to point to non-headings, it will be a
>> major breaking change that may affect third-party packages. So, we
>> need to design the extended ids carefully to avoid breakage.
>
> A defcusom user options whether id:UUID links for non-heading elemen
On 21/10/2023 20:05, Ihor Radchenko wrote:
Tor Erlend Fjelde writes:
I was wondering if there's a reason why we couldn't have IDs a la
org-id.el for everything? It seem to me that it would be useful to use
something like `#+ID` in place of `#+NAME` for tables, blocks, etc. as
well as headlines.
Tor Erlend Fjelde writes:
>> If we simply allow id: links to point to non-headings, it will be a
>> major breaking change that may affect third-party packages. So, we
>> need to design the extended ids carefully to avoid breakage. For
>> example, `org-id-find' and other API function may need to w
> Although we have at least one caveat that we need to consider - the
> current users of the id: links blindly assume that they always link to
> headings. This includes many third-party packages, like org-roam.
>
> If we simply allow id: links to point to non-headings, it will be a
> major breaki
Tor Erlend Fjelde writes:
> I was wondering if there's a reason why we couldn't have IDs a la
> org-id.el for everything? It seem to me that it would be useful to use
> something like `#+ID` in place of `#+NAME` for tables, blocks, etc. as
> well as headlines.
This has been discussed in the past
> What could be the added benefits of having such a header argument? I can
> think of this benefit: #+NAME would be used for referencing them through a
> human-friendly name and the name could change and the #+ID would be an UUID
> that is not expected to change.
This is indeed one use-case I h
Currently, headlines can have an ID (see minimal working example below):
#+BEGIN_SRC org
* My headline 1
* My headline 2
:PROPERTIES:
:ID: e8745be0-906d-4e02-b427-d298f5751f6c
:END:
#+END_SRC
Blocks can't have IDs, but you could use a UUID as the for blocks (see
minimal working example below). Yo
Hi all,
I was wondering if there's a reason why we couldn't have IDs a la org-id.el for
everything?
It seem to me that it would be useful to use something like `#+ID` in place of
`#+NAME` for tables, blocks, etc. as well as headlines.
Would this go against the intended design of org-id.el, or is
10 matches
Mail list logo
