|
From: | Max Nikulin |
Subject: | Re: [BUG] org-store-link-functions advertizes that the first non-nil return value is used, but it is not how org-store-link handles it |
Date: | Tue, 27 Sep 2022 18:39:40 +0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 |
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 addReading 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.
[Prev in Thread] | Current Thread | [Next in Thread] |