It is not necessary to pollute the front matter with such details.
Files are always relative to the present directory. The linking
facility is updated to work as intended (per commit 929157d).
This is an update on commit cfe6e98, which was reverted earlier by
8167d0c.
This reverts commit cfe6e98e7b.
We actually need it for making links. Perhaps we can find a way to only
rely on the identifier. Will need to check this further.
Links will now always be relative to the current directory and use the
standard "file:" prefix.
This means that other packages, like org-transclusion, will work with
our notes without further tweaks.
Jack's contribution is below the ~15 line threshold that is required for
projects that are distributed via GNU ELPA (denote will be one of them
in the near future).
Contributions exceeding that limit require that the author assigns
copyright to the Free Software Foundation.
This is not limited to notes that were created with Denote: it works on
any file in any directory. The idea is to apply the Denote-style file
name in more contexts, such as for longer-term storage and attachments
to notes.
Also see commit 431124f, which is thematically aligned with this one.
Thanks to Ypot for giving me the idea in issue 1 over at the GitHub
mirror: <https://github.com/protesilaos/denote/issues/1>.
There is no need to limit it to the denote-directory. We ultimately
want to fontify all Denote-style file names, not just the notes created
by Denote.
For example, I have been recording all my longer-term storage using such
a naming scheme: this mode gives me the extra faces for .pdf, .mp3, and
other files.
Users of Denote may want this for attachments.
The upside of having this as a buffer-local mode is that the user can
write a wrapper function that applies the mode only in a given
directory (like we were doing before).
Thanks to Ypot for suggesting a kernel of this idea in issue 1 over at
the GitHub mirror: <https://github.com/protesilaos/denote/issues/1>.
This is because there are other packages which read the filetags for
their purposes. There is no compelling reason to have a non-standard
"#+keywords" for this entry.
Thanks to Kaushal Modi for the feedback, which was sent via email (this
is shared with permission).
