-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
issue with duplicate property drawers when creating org-ids on link creation #92
Comments
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")) (use-package org-super-links 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 |
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)
The text was updated successfully, but these errors were encountered: