Intended functionality of obisidan-capture and obsidian-move-file
jayemar opened this issue · comments
When using obisidian.el, a common workflow for me is to use obsidian-capture to create a new note. This note will be placed in the directory specified by obsidian-inbox-directory, so I'll often want to move that to a different location for which I use obsidian-move-file. But I have a couple of questions about this workflow.
After I create the new note using obsidian-capture, it is not available via obsidian-insert-link unless I restart emacs. I've tried running obsidian-update to see if that would allow the new file to be seen by obsidian-insert-link, but it doesn't. Is this the intended behavior, or should the new note be available for linking as soon as it is created? If so, do I need to change my workflow somehow in order to allow for this functionality?
I often don't want files to live in the obsidian-inbox-directory so I'll eventually move them to somewhere more permanent. However, I may have already linked to them before I move them. So I was wondering if the obsidian-move-file function does anything special to update links in other files that link to the file being moved, or should I be moving files to their final location before creating links to them to avoid breaking links?
I hope this is the proper forum for these questions. Thanks for the great work and the great tool!
Hi, thanks for the message, this is a very appropriate place.
- New notes should be available to insert as links as soon as they are created. It doesn't work like this, appartently, but shouldn't be too hard to fix.
- When following links that only contain file names, obsidian.el looks in the entire vault for notes of the same name. If only one is found it follows the link directly, if more than one — it lets user choose. If there are none it creates a new note.
milespossing maybe you have time to handle it?
I started digging into the code a bit and wanted to provide a little more context to what I'm thinking and seeing.
- I found that adding
(save-file) (obsidian-reset-cache)to the end of theobsidian-capturefunction makes it works as I was expecting. It turns out the file doesn't yet exist when the defaultobsidian-capturefunction exits, hence the need to callsave-filebefore resetting the cache. I'm not familiar enough with the code to know if there's a more elegant way for accomplishing this. - I believe obsidian.el is working as you described. What I was wondering if
obsidian-move-fileupdates the backlinks pointing to a file being moved so as to not break existing links, and I believe the answer is that it does not. What I'm seeing is that if A links to B, and then I move B to a new directory, that the link from A no longer resolves to B and so runningobisidian-follow-link-at-pointwill create a new file at the previous location of B.
For case 2, I do see that if the path does not include a directory, that is if it's only the name of the file, then moving the file does not break the link because obsidian.el will look through the entire vault for a file with that name. However, because I'm setting obsidian-inbox-directory to inbox, all of my newly-created file links include /inbox/<new-file-name>.md; in this case, if the file is moved, obsidian.el is unable to resolve this path and ends up creating a new file in the original location.
A simple partial solution for me would be to stop setting obsidian-inbox-directory so that all newly created files are simply the filename without a path. If I then link to these files, the link will only be the filename, and if I later move the file then they will still resolve. But if I link to a file after moving it, and then move it again, those links would again break. So a full solution would probably involve looping through the backlinks to a file and updating all of them when a file is moved, but this would obviously be much more involved so probably more of a feature request than a bug fix.
I didn't realize that Obsidian proper inserts links that include only the filename without the path. This is actually an easier solution to my issue #2 above, and then relying on the existing obsidian.el functionality to find the file without that name anywhere within the vault.
This just required modifying the function obsidian--request-link. I changed the code:
(chosen-file (completing-read "Link: " all-files))
(default-description (-> chosen-file file-name-nondirectory file-name-sans-extension))to:
(chosen-file (file-name-nondirectory (completing-read "Link: " all-files)))
(default-description (file-name-sans-extension chosen-file))Now links inserted via obsidian-insert-link will just include the filename without any of the path information, so moving files around will no longer break links.
If you are interested in this change (and my simple changes seem sufficient) let me know and I can submit pull requests, separate ones for 1 and 2 above. I realize 2 is a breaking change as it modifies the existing way that link insertion works, so no problem if you're not interested. I've made the changes to my local obsidian.el file.
Great job! I'm interested in both, please prepare the PRs!
In order for the insert link not to be breaking you can make this it's alternative behavior with a prefix command argument: https://www.gnu.org/software/emacs/manual/html_node/elisp/Prefix-Command-Arguments.html
So calling it with C-u would only insert file name.
After thinking a little more, I think it should be the other way around: full path should be the alternative behavior which would simplify a lot of things. It will not be a breaking change, because the existing links will keep working.
That sounds good, I like the idea of the filename being default with the full path as the alternate behavior.
Do you think it would make sense to have a setting available to toggle the default mode, something like obsidian-links-use-vault-path that is set to nil by default? Then if someone wants to use that workflow they can set that to t and not need the prefix. I still like the idea of the prefix being available for one-off link creation.
Alright, I ended up creating 3 different PRs, one each for each of the issues discussed here, as well as one other as it didn't seem like the file list was being updated during the call to obsidian-update.
I tried to follow your style as much as possible, but if you'd like me to change anything functionally or stylistically just le me know.