Fuzzy links can now be auto-replaced on navigation and on file-save, if
there is already a match. This is now the default behaviour, controlled
via `org-roam-auto-replace-fuzzy-links`.
When using gpg encrypted files it might happen (intended) that on a
certain machine there is no key to decrypt that file. Currently an
error of type 'file-error' will be raised and the cache building
process will be aborted. So in a certain sense org-roam will not
be functional in that case. Furthermore, when the the cache building
process is run from the emacs initialisation it will come to a halt as
well and the user will be left with a halfworking emacs instance.
This patch changes the behaviour to just skipping over offending files
while removing them from the db at the same time. Here an offending
file is any file that cannot be read for indexing. As it stands this
case only works reliably for the case of missing gpg keys.
An error buffer will still show up and be prominently displayed,
besides a log to the message buffer.
Implementation note: This io error will only be caught during the
first part of the cache rebuilding ("files and headlines"). If such
an error would occur during the second part ("rebuild the rest")
another (more severe) cause might be the problem and the user better
be informed the hard way (i.e. the same behaviour as before).
This PR enables the long-awaited nested-captures.
1. Adds a hook to org-capture-prepare-finalize-hook, which installs org-roam-capture--finalize into org-capture-after-finalize-hook if the capture is an Org-roam capture. This function contains key functionality for Org-roam to Do The Right Thing after specific interactive functions, such as finding the file, or inserting a link.
2. A patch for org-capture-finalize. Specifically, we make org-capture-plist valid during org-capture-finalize.
3. Many hacks that were originally in place are now replaced with nicer alternatives.
Co-authored-by: Leo Vivier <zaephon@gmail.com>
Before this patch all hash-sums were computed over the files or
buffers content. For encrypted files this means that we first have
decrypt the file before we can compute the hash-sum. So when the
cache get's updated all gpg files need to be decrypted which is a very
expensive operation and nearly defeats the purpose of having a cache
in the first place (for gpg files).
This changes the computation of hash-sums for gpg encrypted files.
Instead of the content the raw files on disk will be read.
This shouldn't interfere with the current use of hashes.
There is one ugly (but otherwise inconsequential) ward, though.
For open buffers of to be gpg encrypted files we need to compute the
hash sum over the contents as well. This is because there is
no (easy) way to get the encrypted version. The consequence is that
that buffers file will be rehashed again (then using the bytes on
disk). But all other non changed gpg files will only be hashed once,
as desired.
Co-authored-by: Jethro Kuan <jethrokuan95@gmail.com>
Fixes#956.
The extraction of links rely on appropriate regexp being set for
outline-mode, to determine the outline information. Because the
information were extracted in a temporary buffer, the outline regexp was
not set. This corrects for that, but probably adds significant
extraction time.
* (fix): Check if link-description is empty prior to inserting in db
Caused problems with plain links, i.e., those not framed by
brackets (e.g. `file:foo.org` or `id:$uuid`).
* (feat): Add customize settings to `org-roam-capture-templates`
Declare `org-roam-capture-templates` with `defcustom` and update the
docstring.
Co-authored-by: Leo Vivier <leo.vivier+dev@gmail.com>
7f56df7f4d introduced the delta symbol in the
db-rebuild message to make it clearer the the db was updated as opposed to
being completely rebuilt.
However, the unicode symbol used, U+1D6AB, which is the mathematical, bold
variant of the Greek letter is not present in many fonts. Switching to
U+0394, the base Greek letter, is better for compatibility.