A system of information management
Vanilla Emacs does the job.
Over the past several months I have been experimenting with different mechanisms for personal information management, particularly when reading source code and other computer-related subjects. After many iterations, I have developed a system that I feel works for me based on Emacs and Org.
Like any system, there are some foundational elements to make everything work. In this case, the foundational unit of the system is the note. Notes are represented as Org entries with two particular characteristics. The first is that each note has a unique ID, but not necessarily a fixed location in the system; notes can be moved around as needed. The ID of a note is stored in the ID property of the entry. The second is that notes generally include a source link that Org itself can understand, such as files, HTTP URLs, or other notes. (I say "generally" because there are occasions when a note contains material that is helpful to me which does not have an obvious source, such as a code snippet or useful shell command.) This allows the system to function as a sort of compressed representation of things I have read with an overlay of hyperlinks between those things. An example of such a note is below (line breaks added for readability):
** gitglossary(7)
:PROPERTIES:
:ID: d1cfcf17-8da5-4203-a5c6-25652cd1d314
:TIMESTAMP: <2026-08-16 Sun>
:END:
gitglossary is a glossary of Git-specific terms. It is particularly useful \
for looking up pathspecs, as it is the only place where pathspec logic is \
actually defined.
[[man:gitglossary][Source]]
Notes intentionally do not include other metadata, such as tags. This is because the purpose of the system is to provide an enriched overlay on top of source material with minimal commentary about the material itself. Tags get in the way of this by adding a mechanism to describe what an item is "about", and thus have been omitted from the system.
To make the collection of notes easier to traverse, I store notes in a single agenda file organized at two levels: first by type of source, and then by source if needed. The latter is typically only necessary when referencing larger bodies of work, such as source code repositories or books. The following partially-expanded tree of notes shows how this looks in practice:
* Links
** Generated sequences in Postgres
* Man pages
** gitglossary(7)
* Emacs manuals
** Org
*** Additional hyperlink types
*** Search view
*** Capture templates
* Unfiled
** Global and local cycling
Leveraging built-in Org features allows for rapid capture of notes using capture templates. I currently have three capture templates for analyses (items with no source), links (items with a source link), and references (items with a source pointing to a file on disk). While these could probably be consolidated in some way, they are an effective mechanism for capturing different kinds of information. All notes go into a designated section called Unfiled at capture time to reduce the time required to actually record a note. The templates are as follows:
(setq org-capture-templates
'(("a" "Analysis" entry (file+headline "~/org/zet.org" "Unfiled")
"* %^{Title}\n:PROPERTIES:\n:ID: %(org-id-new)\n:TIMESTAMP: %t\n:END:\n\n%?")
("l" "Link" entry (file+headline "~/org/zet.org" "Unfiled")
"* %^{Title}\n:PROPERTIES:\n:ID: %(org-id-new)\n:TIMESTAMP: %t\n:END:\n\n%?\n\n[[%^{URL}][Source]]")
("r" "Reference" entry (file+headline "~/org/zet.org" "Unfiled")
"* %^{Title} (%f)\n:PROPERTIES:\n:ID: %(org-id-new)\n:TIMESTAMP: %t\n:END:\n\n%?\n\n[[%L][Source]]")))
With a mechanism established for recording information, the next part of the problem becomes retrieving what has been recorded. Org is useful here as well, with a simple but effective syntax for searching agenda files. This is particularly useful when searching through the bodies of notes rather than headings. A search for org may return several entries that mention Org, while a search for +org +search will return any entry that contains both the (case-insensitive) strings org and search. In my personal file, this exact search yields the following entry:
*** Search view
:PROPERTIES:
:ID: 4ed379a7-ae20-4a98-a1a7-56f58dba948c
:TIMESTAMP: <2026-08-16 Sun>
:END:
The Org agenda view allows for searching for keywords within agenda files. \
Org search has support for searching for substrings (with whitespace trimmed) \
and boolean search. For the latter, use the + and - operators to include and \
exclude items respectively.
For example, the search string "x.509 certificate" will look for any string that \
is a (case-insensitive) match for "x.509 certificate", while a search for "+x.509 \
+certificate" will look for any search that includes both "x.509" and "certificate".
[[info:org#Search view][Source]]
Finally, to minimize the effort required in the process of filing and retrieving notes, I have a small number of key bindings for storing links, pulling up the Org agenda view, and capturing entries:
(use-package org
:hook
((org-mode . visual-line-mode))
:bind
(("C-c l" . org-store-link)
("C-c a" . org-agenda)
("C-c c" . org-capture)))
Additional key bindings built into Org include C-c C-w (refile entry under another heading) and C-c C-l (insert link in Org entry).
After accumulating enough notes, I go through unfiled entries and place them in appropriate portions of the tree of notes. This leads me to revisit material I have already written, avoiding the pitfalls of other write-only information management systems, while simultaneously building up a richer understanding of how each piece of information fits in a broader context.
Overall, I have found this system most useful for processing and navigating large source code repositories. My workflow for doing so starts by capturing a note for any function I have not yet seen before and writing a few sentences describing it. If the function calls a function I have processed previously, I add a link to that function. If that function calls some other function I have not yet processed, I go to that function's definition (typically by using Eglot) and capture a note describing that function, recursively continuing until I get to some acceptable level of understanding. Once this is done, I link the notes to one another as needed and file them under a note for their containing repository or repositories. When I need to reference something in a repository I have already processed, it is typically only a single C-c a s away.
I have noticed two effects from consistently applying this habit (and importantly, by remaining in the same context of Emacs and Org) over several months. The first, more obvious effect is that it is easier to retrieve notes about things I have read without relying on tools like search engines. The second is that the system provides a richer background context when reading both familiar and new material, leading to faster processing of material that ultimately feeds back on itself.
While I primarily developed this system to help me go through source code, I have found it useful enough that in recent weeks I have started to pull more sources of material in, such as man pages and Emacs manuals. The former has been made much easier thanks to Org's support for additional hyperlink types (their canonical example being a man page link type). Should this prove to be useful, I will likely continue and begin processing books and other sources in a similar fashion.
I will end this post by noting that while this system is specific to a particular method of using a particular text editor, nothing about it requires Emacs or Org. It is likely that any combination of text editor, key bindings, and half-decent search would do just as well in a different environment.