I donât know how useful this will be in general given how dependent a lot of this is on the mechanical qualities of how I archive textâbut here are three ways you can do this with a system that is set up like mine.
Firstly, yes, I was using the word âbeaconâ to describe a type of âbinding noteâ. The important concept to grasp there is that any note can become a binding note, in a similar way Zettalkasten works (I think), but some notes in my system pretty much exist solely for that function, rather than actually being something else first (like a chat log to tech support) that ends up being so cross-referenced that it binds a bunch of technical resolution stuff together.
It has a formal classification too, rather than my casual use of the word âbeaconâ, which we might as well get intoâŚ
Command-line tools
You may have no interest in CLI stuff, but donât skip it, as this is where Iâll explain the mechanics of the system a little bit.
$ find . -iname "*i1.1.thread*note*"
./ark/22/22334834 I1.1.Thread using scrivener as a note-taking tool.md
ag -l 22334834
(Many Markdown files are returned...)
We start with the native find tool to look for any titles that contain the phrase âi1.1.threadâ and ânoteâ, case-insensitive. Asterisks can be used wherever you are unsure, the more you leave to âglobbingâ or wildcards, the fuzzier your results, but that might be just what you need if you barely remember anything about what youâre looking for.
The line after that prints the result, the path to the Markdown text document that serves as the âbeaconâ for this particular thematic cluster of thoughts: âUsing Scrivener as a Note-Taking Toolâ.
âI1.1.Threadâ means: âInformation.Internal.Meta.Threadâ. I1 relates to any form of information I generate for myself, like I1.2 which tracks all productivity notes, tasks, projects, etc. I1.1, or âmetaâ tracks information about the very archive itself, or its usage, within which we are interested in threads, common ongoing topics that get written about a lot.
If you do this all of the time, and you know your own taxonomy like the back of your hand, at this point youâre about 10 seconds into the look-up (less if you alias âfind . -iname $1â to an abbreviation like I do).
And now I have that âbeaconâ noteâs ID number printed to the console, which is the compact date stamp at the beginning of the file name, â22334834â. That is not only this noteâs date and time of creation, but its unique ID number among all other notes. Thus, if I run a full content search for this ID number across all notes, I will find everything that refers to it somewhere within its text or metadata block.
Now for the third line, which depends upon an excellent multi-platform utility, The Silver Searcher. This is a super fast command-line search tool that, like grep, can trawl through hundreds of thousands of text files in a fraction of a second, and the -l flag makes it return only a list of relative paths to files, rather than including a hit synopsis (like a web search might do). I get a list of note filenames, such as in this excerpt:
ark/22/22240405 M2.1.Usage building a ticketing system for tracking edits.md
ark/22/22308894 M2.1.Usage on the benefits of freeform tools for notetaking.md
ark/22/22334800 M2.1.Usage scrivener and bi-directional linking.md
ark/21/21031547 M2.1.Usage project template for scratch pad replacement.md
From there I could run gvim ark/21/21031547 (gvim being my text editor of choice for this kind of stuff), hit Tab to auto-complete the rest of the name and open the file for âProject Template for Scratch Pad Replacementâ. If I was just looking for that one note out of the list, Iâm at maybe 20 or 30 seconds into the search, most of which was spent look through titles, and could be trimmed by adding âscratchâ to the search. Iâve gone from nine million words and hundreds of thousands of files to that one thing I wanted in well under a minute.
But I have other tools for other tasks. Say Iâm looking for the URL because I want to read it in a browser instead of a text editor, head -10 ark/21/21031547 and Tab will get me that, as this prints the first 10 lines of the file to the console:
$ head -10 ./ark/21/21235531\ M2.1.Usage\ \ setting\ up\ a\ default\ project\ notes\ scratchpad.md
---
Title: Setting Up a Default Project Notes Scratchpad
Author: AmberV
Date: '21235.531'
URL: 'https://forum.literatureandlatte.com/t/way-to-have-notes-stay-open-in-inspector-regardless-of-file-or-folder-chosen/119315/24?u=amberv'
Tags: '{M2.1.Usage}'
Aliases: '21235531'
Domain: LnL
PDSVersion: v20340
---
But if youâre a nerd like me, system tools like that are good to know and use, but if you do that a lot, youâll want to write your own scripts that parse Markdown metadata and give you what you want. For example:
ag -l 22334834 | mdmeta -url
This takes the search result list and pipes it to a script that would print the full Markdown metadata block for a list of given filesâbut with the -url flag only prints the URL values, one per line. I might instead want to use the -seealso flag, which would print the interconnection references between items that make this stuff work, where I would at the least find âm:22334834â among each of them (most likely) which means itâs a meta reference to that IDâthe Thread note we started with on note-taking in Scrivener. That line in the Markdown block is how we got to these files in the first place, and might contain other useful cross-references too.
Pipes are super useful, I can throw another one on after the above, and pipe the list of harvested URLs to my browser, having them all open as tabs in one shot. Once you start gathering, formulating and pushing data around between utilities and even into GUI software that supports CLI access, the possibilities are endless.
Markdown Editors
So thatâs the nerdy âcomputer hackerâ way of doing things, but that is precisely why I like having my notes as files rather than âinsideâ of a database or project like in Scrivener, because I can use system tools like this when I want to, when that is most efficient. But loose files can be useful to other things too, like multi-file text editors, such as Visual Studio Code, Sublime Text and Obsidian.
While these programs tend not to be nearly as fast as Silver Searcher, they do offer certain advantages for browsing. Instead of having to gvim or head -10 each file name Iâm interested in, I can flip through them one by one in a sidebar or something.
Speed aside, most can usually do the above just about as efficiently (usually with more mouse waving though). For example in Obsidian there is a saved search for âI1.1.Threadâ, which I can then add ânoteâ to the search term, that returns the note-taking thread with its text in the main viewer. I double-click its ID to select it, and press CtrlShiftF to search for the selected text⌠which returns the full listing Silver Searcher gave me, above. With other programs, the route may be slightly different, but you can get there.
Scrivener
With Scrivener you may have a Search Collection (saved search) for stuff like this, which you can right-click in the editor header bar to load, then CtrlF to filter further if you need. Copy the ID from the binder itemâs name and drop it into Project Search to get the same list of notes.
(On refresh: Or yes, if you were deep into using Scrivener this way, you might want to use Keywords instead of a text-based classification system, as @kewms notes, those work great with Collections too.)
Scrivener is no slouch at racing through interconnected data like this, in other words. I had no complaints with how agile it was. To go back to my âm:22334834â example above, if I saw that in the SeeAlso metadata area, I could right click on the ID number and Scrivener will pull up the note that contains that ID in its name. Click on it, and Iâm off, I donât even have to search.
It might seem funny that Iâve written so much about using Scrivener for taking notes while this system isnât in it, but hopefully the above better illustrates why. If I wasnât a programmer, or I didnât use Markdown and preferred rich text notes (way more difficult to work with using the above tools), then I would be happier with more containment, or I guess a better way to put it is that I would have fewer reasons for things to not be âinâ a softwareâs GUI and by extension be largely inaccessible from outside of it.
That process helped inform and streamline the design of the software though, to be even better for note-taking.