This set of functions aims to implement many (but not all) of the features of the package Zetteldeft, while circumventing and eliminating any dependency on Deft, or any other external packages for that matter. It does not use any backend cache or database, preferring instead to query a directory of plaintext notes directly, treating and utilizing that directory as a sufficient database unto itself.
To that end, these functions rely, at the lowest level, on simple calls to
grep, which returns lists of files, links, and tags to the Emacs completion
function completing-read, from which files can be opened and links and tags
can be inserted into an open buffer.
Out of the box, links are clickable buttons made with the built-in
button.el. This means that links will work the same way in (almost) any
major mode: fundamental-mode, text-mode, outline-mode, markdown-mode, etc.
The key exception is Org-Mode, where a minor change is necessary to enable
clickable zk-links. (See below for details.)
The structural simplicity of this set of functions is—one hopes, at least—in line with the structural simplicity of the so-called “Zettelkasten method,” of which much can be read in many places, including at https://www.zettelkasten.de. Ultimately, this package aims to be a lean, understandable, and eminently forkable Zettelkasten implementation for Emacs. Fork away, and make it your own.
Notes are all kept in a single directory, set to the variable zk-directory,
with no subdirectories.
Each note is a separate file, named as follows: a unique ID number followed
by the title of the note followed by the file extension (set in the variable
zk-extension), e.g. “202012091130 On the origin of species.txt”.
The primary connector between notes is the simple link, which takes the form
of an ID number enclosed in double-brackets, eg, [[202012091130]]. A note’s
ID number, by default, is a twelve-digit string corresponding to the date and
time the note was originally created. For example, a note created on December
9th, 2020 at 11:30 will have the ID “202012091130”. Linking to such a note
involves nothing more than placing the string [[202012091130]] into another
note in the directory.
A key consequence of this ID and file-naming scheme is that a note’s title can change without any existing links to the note being broken, wherever they might be in the directory.
For the best experience completing filenames and links, it is highly
recommended to use the orderless completion style, from the package of the
same name. Another high recommendation is Vertico, for completion in the
minibuffer.
The easiest way to install is from MELPA.
Or, manually add zk.el to your loadpath and include (require 'zk) in your
init.el file.
At a minimum, you must set the variables zk-directory and
zk-file-extension:
(setq zk-directory "~/path/to/your/zk-directory")
(setq zk-file-extension "md") ;; any plaintext file extension, eg, "org" or "txt"Once zk is loaded, call M-x zk-new-note to create a note or M-x zk-find-file to
open an existing note.
- To enable automatic link-creation when opening a zk-file, include the function
(zk-setup-auto-link-buttons)in your init config. This ensures thatzk-enable-link-buttonsis set totand addszk-make-link-buttonsto Emacs’sfind-file-hook. - To enable Embark integration, include the function
(zk-setup-embark)in your init config.
(use-package zk
:custom
(zk-directory "~/path/to/zk-directory")
(zk-file-extension "md")
:config
(zk-setup-auto-link-buttons)
(zk-setup-embark))See Alternative Search Functions, using Consult-Grep
(use-package zk
:straight (zk :files (:defaults "zk-consult.el"))
:custom
(zk-directory "~/path/to/zk-directory")
(zk-file-extension "md")
:config
(require 'zk-consult)
(zk-setup-auto-link-buttons)
(zk-setup-embark)
(setq zk-tag-grep-function #'zk-consult-grep-tag-search
zk-grep-function #'zk-consult-grep))Links are buttons made with the built-in package button.el: they are
clickable text that work the same way in any major mode. Whether in
fundamental-mode, text-mode, outline-mode, or markdown-mode, etc.,
clicking or pressing RET on a zk-link opens the corresponding note. The
only exception is Org-Mode. (See below.) configuring clickable links in
Org-Mode, see below.)
It is also possible to call the command zk-follow-link-at-point
when a link is at point, or call the command zk-links-in-note to be
presented with a completing-read list of all links in the current note.
In Org-Mode, links in the default format zk-link-format (an ID in
double-brackets) will be treated as internal links. This means that when they
are clicked, Org will, by default, look for an in-buffer heading or target
that is named, or contains, the given ID. To make Org treat zk-links as
zk-links and open the corresponding note, it is only necessary to advise the
function org-open-at-point as follows:
(defun zk-org-try-to-follow-link (fn &optional arg)
"When 'org-open-at-point' FN fails, try 'zk-follow-link-at-point'.
Optional ARG."
(let ((org-link-search-must-match-exact-headline t))
(condition-case nil
(apply fn arg)
(error (zk-follow-link-at-point)))))
(advice-add 'org-open-at-point :around #'zk-org-try-to-follow-link)Briefly, this function instructs org-open-at-point to try calling
zk-follow-link-at-point when a link is not an internal link.
An alternative solution for using Org-Mode would be to change
zk-link-format to use, for example, single brackets instead of double
brackets. With this change, the default link buttons will work as expected.
Note that using Org links makes the creation of link buttons, via
zk-make-link-buttons, redundant. This link button aspects of the package
can be disabled by setting zk-enable-link-buttons to nil.
To allow link-hint.el to find zk-links, it is necessary to add a new link type, as follows:
(defun zk-link-hint--zk-link-at-point-p ()
"Return the id of the zk-link at point or nil."
(thing-at-point-looking-at zk-link-regexp))
(defun zk-link-hint--next-zk-link (&optional bound)
"Find the next zk-link.
Only search the range between just after the point and BOUND."
(link-hint--next-regexp zk-id-regexp bound))
(eval-when-compile
(link-hint-define-type 'zk-link
:next #'zk-link-hint--next-zk-link
:at-point-p #'zk-link-hint--zk-link-at-point-p
:open #'zk-follow-link-at-point
:copy #'kill-new))
(push 'link-hint-zk-link link-hint-types)Calling zk-backlinks in any note presents a list, with completion, of all
notes that contain at least one link to the current note.
The function zk-new-note prompts for a title and generates a unique ID
number for the new note based on the current date and time. A new file with
that ID and title will be created in the zk-directory.
The header of the new note is inserted by means of a function, the name of
which must be set to the variable zk-new-note-header-function.
The default header function, zk-new-note-header, behaves differently
depending on the context in which zk-new-note is initiated. If
zk-new-note is called within an existing note, from within the
zk-directory, the new note’s header will contain a backlink to that note.
If zk-new-note is called from outside of the zk-directory, there are two
possible behaviors, depending on the setting of the variable
zk-default-backlink. If this variable is set to nil, the header of the new
note will contain no backlink. If this variable is set to an ID (as a
string), the header will contain a link and title corresponding with that ID.
This can be useful if the directory contains a something like a “home” note
or an “inbox” note.
By default, a link to the new note, along with the new note’s title, will be
placed at point wherever zk-new-note was called. This behavior can be
configured with the variable zk-new-note-link-insert: when set to t, a
link is always inserted; when set to zk, a link is inserted only when
zk-new-note is initiated inside an existing note in zk-directory; when
set to ask, the user is asked whether or not a link should be inserted;
when set to nil, a link is not inserted. Calling zk-new-note with a
prefix-argument will insert a link regardless of setting of
zk-new-note-link-insert.
By default, the date/time of a generated ID only goes to the minute, though
this can be configured with the variable zk-id-time-string-format. In the
default case, however, if more than one note is created in the same minute,
the ID will be incremented by 1 until it is unique, allowing for rapid note
creation.
Finally, a new note can be created from a selected region of text. The
convention for this feature is that the first line of the region will be used
as the new note’s title, while the subsequent lines will be used as the body,
with the exception of a single separator line between title and body. To
clarify, consider the following as the region selected swhen zk-new-note is
called:
On the origin of species
It is not knowledge we lack. What is missing is the courage to understand
what we know and to draw conclusions.The title of the new note in this case will be “On the origin of species.” The body will be the two sentences that follow it. The empty line separating title from body is necessary and should not be excluded.
Note: This behavior is derived from the behavior of an earlier, long-used Zettelkasten implementation and it persists here by custom only. It would be trivial to alter this function to behave perhaps more sensibly, for example by using the selected region in its entirety as the body and prompting for a title. For now, though, custom prevails.
Calling zk-insert-link presents a list, with completion, of all notes in
the zk-directory. By default this function inserts only the link itself,
like so: [[202012091130]].
To insert both a link and title, either use a prefix-argument before calling
zk-insert-link or set the variable zk-link-insert-title to t, to always
insert link and title together. Note that when zk-link-insert-title is set
to t, calling zk-insert-link with a prefix-argument temporarily restores
the default behavior and inserts the link without a title.
To be prompted with a yes-or-no query, asking whether to insert a title with
the link or insert only a link by itself, set zk-link-insert-title to
ask. With this setting, a prefix-argument also restores the default
behavior of inserting only a link.
The format in which link and title are inserted can be configured with the
variable zk-link-and-title-format.
This package includes a completion-at-point-function,
zk-completion-at-point, for inserting links. Completion candidates are
formatted as links followed by a title, i.e., [[202012091130]] On the origin
of species, such that typing [[ will initiate completion. To enable this
functionality, add zk-completion-at-point function to
completion-at-point-functions, by evaluating the following:
(add-hook 'completion-at-point-functions #'zk-completion-at-point 'append)
Consider using Corfu or Company as a convenient interface for such completions.
The default search behavior of zk-search calls the built-in function
lgrep to search for a regexp in all files in zk-directory. Results are
presented in a grep buffer.
The function zk-find-file-by-full-text-search presents, via
completing-read, a list of all files containing at least a single instance
of a give search string somewhere in the body of the note. Compare this to
zk-file-file which returns matches only from the filename.
There are two functions that query all notes in the zk-directory for tags
in following form: #tag. One of the functions, zk-tag-search, opens a
grep buffer listing all notes that contain the selected tag. The other
function, zk-tag-insert, inserts the selected tag into the current buffer.
The file zk-consult.el includes two alternative functions, for use with the
Consult package, that display the results using completing-read.
To use, make sure Consult is loaded, then load zk-consult.el, and set
the following variables accordingly:
(setq zk-search-function 'zk-consult-grep)
(setq zk-tag-search-function 'zk-consult-grep-tag-search)This package includes support for Embark, both on links-at-point and in the minibuffer.
To enable Embark integration, evaluate the function zk-setup-embark. Include this
function in your config file to setup Embark integration on startup.
When Embark is loaded, calling embark-act on a zk-id at point makes
available the functions in the keymap zk-id-map. This is a convenient way
to follow links or to search for instances of the ID in all notes using
zk-search.
Calling embark-act in the minibuffer makes available the functions in
zk-file-map. This is a convenient way to open notes or insert links.
Additionally, note that because the function zk-current-notes uses
read-buffer by default, all Embark buffer actions are automatically
available through embark-act. This makes killing open notes a snap!
Last note: adding zk-search to other Embark keymaps is a convenient way to
search all notes for a given Embark target. Consider adding it to the
embark-region-map, for example, with a memorable keybinding — like “z”!
The function zk-current-notes presents a list of all currently open notes.
Selecting a note opens it in the current frame.
The command can be set to use custom function, however, by setting the
variable zk-current-note-function to the name of a function.
One such function is available in zk-consult.el: zk-consult-current-notes
presents the list of current notes as a narrowed consult-buffer-source.
Note that this source can also be included in the primary consult-buffer
interface by adding zk-consult-source to list consult-buffer-sources.
(This is not done by default.)
- Emacs-based
- Non-Emacs
You should! They are great. I used each one of them for a least some time, some for longer than others. At a certain point with each, however, I found that I couldn’t make them do exactly what I wanted. My sense, eventually, was that the best implementation of a Zettelkasten is the one in which a user has as much control as possible over its structure, over its behavior, and, frankly, over its future viability. At first, this primarily meant using only plaintext files — no proprietary formats, no opaque databases. Eventually, however, it also meant seeking out malleability and extensibility in the means of dealing with those plaintext files, ie, in the software.
My best experiences in this regard were with “The Archive” and, after I discovered Emacs, with “Zetteldeft.” The former is highly extensible, largely by virtue (at least at this point) of the macro editor “KeyboardMaestro,” through which one can do nearly anything with a directory of text files, in terms of editing, querying, inserting tags and links, etc. If I hadn’t fallen into Emacs, I would definitely still be using “The Archive” in combination with “KeyboardMaestro.” Little about my note-taking practices and preferences has changed since I used “The Archive.” As for “Zetteldeft,” the notable differences between it and the present package are only to be found under-the-hood, so to speak. The only reason I’m not still using it is that, over time, it became this.