Open iantor opened 7 months ago
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.
:+1: 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.
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)