Additional file: link in org-stored-links candidate

[TomoeMami]

My versions:

~/.emacs.d/org/journals $ (emacs-version)
GNU Emacs 31.0.50 (build 2, aarch64-apple-darwin24.3.0, NS appkit-2575.40 Version 15.3.1 (Build 24D70))
 of 2025-02-25
~/.emacs.d/org/journals $ (org-version)
9.7.26

When I call org-store-link interactively, the first candidate of org-insert-link would be a link started with file: instead of denote:.

I think it's the additional "human-readable" link stored by org-store-link in ol.el :

https://github.com/bzg/org-mode/blob/b6dbf8881076191e1351d7cd15e26547a2531fea/lisp/ol.el#L1942-L1952

        ;; In org buffers, store an additional "human-readable" link
        ;; using custom id, if available.
        (when (and (buffer-file-name (buffer-base-buffer))
                   (derived-mode-p 'org-mode)
                   (org-entry-get nil "CUSTOM_ID"))
          (let ((here (org-link--file-link-to-here)))
            (setq link (car here))
            (setq desc (cdr here)))

And we have this in denote.el:

denote/denote.el

Lines 5713 to 5723 in e41fd8e

	(defun denote-link-ol-get-id ()
	"Get the CUSTOM_ID of the current entry.
	If the entry already has a CUSTOM_ID, return it as-is, else
	create a new one."
	(let* ((pos (point))
	(id (org-entry-get pos "CUSTOM_ID")))
	(if (and (stringp id) (string-match-p "\\S-" id))
	id
	(setq id (org-id-new "h"))
	(org-entry-put pos "CUSTOM_ID" id)
	id)))

So I currently just redefined denote-link-ol-get-id with ID, and it works normally:

(defun denote-link-ol-get-id ()
  (let* ((pos (point))
         (id (org-entry-get pos "ID")))
    (if (and (stringp id) (string-match-p "\\S-" id))
        id
      (setq id (org-id-new "h"))
      (org-entry-put pos "ID" id)
      id)))

Is there a workaround to fix the first candidate issue without redefinition ?

[protesilaos]

I suspect it may be related to issue 556, which was addressed by the Org maintainer. Unfortunately, I cannot access Savannah right now to review what changed in org.git.

[protesilaos]

That granted, does the following work for you (while undoing the change you made):

(setq denote-org-store-link-to-heading nil)

[TomoeMami]

As the denote manual shows, it produces links only to the current file, without additional links.

[TomoeMami]

(lambda () (interactive)
    (denote-link-ol-store)
    (let ((link (plist-get org-store-link-plist ':link))
          (desc (plist-get org-store-link-plist ':description)))
      (org-link--add-to-stored-links link desc)))

While undoing the change I made, I use this little script binding to another key, which bypass the org-store-link funcion, without addtional link stored.

[protesilaos]

I noticed issue #548 right now and I commented there. This is not the desired behaviour and we need to fix it.

[TomoeMami]

This issue existed in latest denote package, because it's upstream org code related.

I think we can advice org-store-link function to clean the extra "human-readable link":

(defun my/clean-org-stored-links (&optional args interactive)
  "Display a custom message after org-publish is done."
  (let((link1 (car (nth 0 org-stored-links)))
       (link2 (car (nth 1 org-stored-links))))
    (when (and (and (string-match-p "^file:" link1) (string-match-p denote-id-regexp link1))
               (and (string-match-p "^denote:" link2) (string-match-p denote-id-regexp link2)))
      (setq org-stored-links (cdr org-stored-links)))))
(advice-add 'org-store-link :after #'my/clean-org-stored-links)

[protesilaos]

I have not looked into how Org works in this case. In general though, I prefer to avoid the advice mechanism unless it is absolutely necessary. The reason is that it has a global effect, which might lead to weird issues. Maybe there is some less intrusive way of achieving the same result. Also, we do not know if people rely on this behaviour right now.

[TomoeMami]

Certainly, the best solution would be for the upstream to add a control variable for this ”human-readable“ link.