On 27/09/2022 08:40, Ihor Radchenko wrote:
Max Nikulin writes:
There is the `org-store-link-plist' variable used by :store functions
from `org-link-parameters' but not by the
`org-create-file-search-functions' hook. Maybe it is enough to add
Reading through `org-store-link-functions' docstring and
`org-store-link' code, I noticed that `org-store-link-functions'
promises the following:
...
That is, all the store link functions are actually being executed, not
until first non-nil return value. If multiple non-nil values are
returned, an interactive query is displayed to the user.
The actual behaviour is indeed nice, but I am wondering how it is going
to work in non-interactive case.
There are more inconsistencies. For a heading in an Org file 2 links may
be created: title search and #custom_id. Only one link is removed by
`org-insert-link'. Only one of them is checked if it has been stored
earlier. Usually after several store+insert actions I have a list of
stored links that I will never use. I am unsure what is better, to
prompt user when link is saved, or store all options with some group ID
and remain other links when one item from the group is inserted.
I suppose, `org-store-link' should be split into smaller building blocks
to allow experiments with alternative implementations and strategies to
select from several variants.
I was wrong suggestion that changing of :store property of "file" links
may be a workaround for original issue. It is easy to store line number
instead of search text, but there are a lot of code to detect headings,
#custom_id, <<target>>, etc. for "file" links and this code can not be
easily reused.
