toshism/org-super-links

issue with duplicate property drawers when creating org-ids on link creation

Opened this issue · 13 comments

Just trying latest org-super-links (using native compilation)
org-mode version 9.6.21
emacs version 29.1

I tried the settings recommended for org-id in the docs:

(require 'org-id)
(setq org-id-link-to-org-use-id 'create-if-interactive-and-no-custom-id)

However, this sometimes produced multiple property drawers in an entry, with a new drawer to contain the org-id.

The following setting seems to work better (still testing)

(setq org-id-link-to-org-use-id t)

Still getting duplicate property drawers with this setting.

(setq org-id-link-to-org-use-id t)

will continue to test and will trace code which creates id. Something is fishy there.

The conclusion of my testing is that there are problems with org-id support in org-super-links. I will continue testing without the use of org-id (using traditional org-mode links) and will report on my results.

Interesting, thanks for investigating. Please report back if you find anything. I have still not moved to 29 yet, possible something changed I suppose.

will do.

I'm going to try disabling native compilation for this library

Ok I have some more info. I have disabled native compilation of org-super-links as follows (there were a couple of related libraries for which I blocked native compilation with a regex in two global variables):

(setq native-comp-jit-compilation-deny-list '("worf" "org-super-links"))
(setq native-comp-bootstrap-deny-list '("worf" "org-super-links"))

(use-package org-super-links
:straight (org-super-links :type git :host github :repo "toshism/org-super-links" :branch "develop" :build (:not native-compile))
:bind (("C-c s s" . org-super-links-link)
("C-c s l" . org-super-links-store-link)
("C-c s C-l" . org-super-links-insert-link)))

I then re-enabled org-id support:

(require 'org-id)

(setq org-id-link-to-org-use-id 'create-if-interactive-and-no-custom-id)

Now tested several times, id was inserted without error (no extra property drawers created), but creation of bi-directional link takes up to 90 seconds. (this was the case on some occasions before I disabled native compilation of the package and dependent packages).

I will continue my testing and tolerate the delay for now.

Decided to stop using org-id because of the speed issue. Switched back to traditional org links and now things are very fast even in a rather large file (1.4 MB). Everything else seems very stable with native compilation disabled. Will continue testing.

While reverting to the traditional org-links approach, I had an unusual cache error followed by significant data loss in the org file. Fortunately, I commit org files to git so I was able to revert by a day. I will continue to test and see if this error happens again.

I think that the cache error I found may have been caused by a problem with org-capture templates (didn't find anything online about this). It seems that if no default value is provided in an org-capture template prompt element, and the prompt is skipped, bad characters are inserted in the capture buffer. Found this using whitespace-mode and org-lint. I added default values for all prompted and user-entered values. Will continue testing. I will also review the org-capture source to better understand what might be going on.

I have decided to try org-super-links again and have had a better experience. I realized that I may have been doing something wrong on my first try (inserting a super link in a field inside the property drawer). Now I only insert links outside the property drawer, no problems so far. I am keeping native compilation disabled for the time being.

oh interesting, thanks for the update. yeah, i can imagine inserting a link into a property drawer could potentially lead to weirdness.

If you have your own workflow already based around drawers you can control the org-super-links drawer behavior with org-super-links-backlink-into-drawer and org-super-links-related-into-drawer which could be helpful to just keep org-super-links from interfering with your existing workflow.

Thanks for confirming my impression of the issue with inserting into a property drawer. I will explore the functions designed to insert links into drawers. I have also enabled native compilation of org-super-links and haven't seen any problems.

👍 and just to be clear, you can disable the drawer functionality of org-super-links completely with the two settings i linked above as well, if that fits into your workflow better. it may play better with your own drawer setup. just set them both to nil and org-super-links will not manipulate any drawers on it's own.