Sometimes I want to select a markdown note from the shell for further work. Maybe I want to launch an LLM with the note or I want to edit the note from within a terminal to fix some bug.

Since I've discovered fzf and its preview feature I find more and more uses for it. The following shell script shows all notes that contain a given label and offers them for selection:

#!/bin/bash

# Maybe we can even get tab completion here?!
LABEL=$1; shift

find ~/bin/App-notes-htmx/notes_corion/ -maxdepth 1 -name '*.markdown' -print0 \
  | xargs -0 grep -l -- " - $LABEL" \
  | perl -lpe 'BEGIN{$\="\0"; s!([\s/*?])!\\$1!g }' \
  | fzf --read0 --preview='cat {}'

Having not only a selection but also a custom preview makes things convenient. Perl was useful for properly escaping the filenames. fzf has the --read0 option, but it still passes the item to the shell without escapes. Using double quotes around the {} does not work.

My Note taking tool is part journal, part shopping list, part blog posts, part programs. Most notes get written once. Some get revised, some get posted or implemented. The tool is fully self-hosted and written by me, so I get to decide on its (lack of) features. For simplicity I avoided keeping a full note history. But then I realized that maybe some kind of history is actually nice, for the case when a wonky network failure erases or corrupts some note.

My solution for this feature is to simply snapshot the directory where I keep my notes every hour into a git repository. This gives me some change history, but it does not record every keystroke. The cron job is the following shell script:

SOURCE=/home/corion/bin/App-notes-htmx/notes_corion
TARGET=/home/corion/backup/notes_corion_history
if git --git-dir=$TARGET --work-tree $SOURCE diff --quiet; then
    git --git-dir=$TARGET --work-tree $SOURCE add  --all
    git --git-dir=$TARGET --work-tree $SOURCE commit -m "Hourly"
fi

I've "implemented" the tool as a shell script, but if I add more features, I will likely move it to Perl and use Git::Raw to do the adding/filtering/pruning myself. But then I would lose the convenience of .gitignore for example.

I still have on my list some kind of git history-prune, that coalesces adjacent git commits if they are too close, just to eliminate changes that don't matter anymore. Maybe after a month, compress all commits older than one month and less than 24 hours apart into a single commit.

I think having all changes of a single day in one commit is a sensible granularity for my use case.