jgarte / zettelkasten

Apparently, it's called a zettelkasten, not a "drafts branch for your blog"

Org Roam:

Reorg: The Reorganization....

This may not be updated very often, but it’s very helpful for me to see how other people organize/use software like emacs, org-agenda, org-roam, etc.

TLDR: YAGNI

• The most useful thing here (See below in code) is a system that enables you:
  • to maintain a system of code.org nodes while using repo sync *...* to track up-to-date git repositories
  • while using org-roam, org-store-link and orgit-store-link to increase the salience/retention of important information in many codebases (even when they are unfamiliar).
• This requires:
  • Setting expectations for links/paths in a personal information system (and adhering to those expectations).
  • Snippets/capture templates to make tenable maintaining your repo manifest XMLs (which is a little less painful than gitmodules)
  • Misusing the intent behind repo a bit (e.g. I’m misusing groups)
• And finally, it requires thinking ahead quite a lot about ontologies – i.e. systems of categorization for software/projects/etc that “cover the space”.
  • If you don’t think ahead, your links will break. Fortunately, the communities around software projects have usually already done this for you. e.g.:
    • doom-emacs categorizes features & packages into its system of modules.
    • sway has produced a list of wayland-ready software that can be used, which is categorized.
    • Often, the project maintainers have thought quite a lot about this and have structured their Git Forge into groups/projects, which are accessible via API.
  • The emphasis is here bc repo will automatically move paths & git repos around. So automated means of generating this XML’s, which act as the basis of URI’s for your programming personal information system, may result in unintended consequences.

finish explaining paths/organization

system of tagging git repo/project directories with org-roam-id’s

• use as a basis for creating backreferences from org-roam files with links that don’t easily break.
  • feed org-roam a list of org-roam-source-paths or something
• can’t create hashs on source files without altering their structure/hash and without impacting sqlite performance (index/etc)
• can use a root hash for the project
  • with subhashs generated deterministically from the hash+path
  • everyone with the same root hash value will have the same hash+path values in org-roam links they generate
  • probably just hash the directories in hash+path, not the files

Paths

art

Notes on art and art-history, including on kapnobatai and optical refinements

code

This directory links out to repo super-projects.

• These, like ectorepo/x.files a collection of dotfiles, are managed via Google Repo. For a better explanation, check out ectorepo/ectorepo.
• Two sibling directories exist outside of /data/org/roam (this repo)
  • /data/repo hosts the Repo manifest XML’s
    • /data/repo/x.files/default.xml defines a list of repos, which are grouped to make repo sync operations a bit easier, in case of broken links.
  • /data/ecto hosts the projects cloned via repo sync
• Each repo project then has a code-.org link back into org-roam
  • e.g. /data/ecto/x.files/code.org links back to /data/org/roam/code/x.files.org
• This means you can use org-store-link to snip links to aid notetaking on large software projects.
  • These links include data on line numbers
  • With orgit-store-link and magit, the links can be associated to git refs.
• Furthermore, you can use anything else that org-mode and emacs offer, which include tools for UML & Diagramming like:
  • Graphviz
  • UML (PlantUML)
  • Or libs like elisp-depmap.el
• Being able to have up-to-date repos in locations that adhere to a simple set of expectations means that, for software like Sway, KDE, Qt, etc, I can quickly search for:
  • Environment variable usages
  • Options or debug flags
  • symbols in stacktraces
• Or for popular dotfiles, I can search for things like
  • org-capture-template
  • export (.*)=(.*)$
• The goal is to avoid searching the internet because that never seems to be efficient.

dailies

For org-roam-dailies

drills

For decks of org-drill flashcards. I intended to use org-capture and org-refile with these decks.

noter

I’m currently tracking my org-noter files in a few different places. However, i would like to create a system that depends on DOI’s (and maybe meshes well with ideas from bibliography databases).

For now, the subdirectories in this noted follow the arXiv and DoI resource identifier structures as closely as possible. The PDF’s are intended to be named according to the DOI. I don’t know enough about bibliography management/software to get this 100% correct … but then again, i still need to configure org-ref and/or org-bibtex.

projects

Projects go here, including links to my

ensure the links are actually necessary for org-roam indexing

meetups

Keeping this in for now, but stuff like this probably won’t get updated.

slips

This folder is named after the ‘slips’ from the zettelkasten method. This is where the majority of notes will be created.

• When nodes in the ./topics path get too large, they may be split off into slips.
• As I see it, there won’t be much linking between slips:
  • they are intended to link to each other via the topics nodes
  • or they should be navitagated by org-roam tags.

topics

These org-roam nodes function like tags, but are intended to catch a lot of backlinks.

While the interactions between topics nodes and slips nodes should have the aforementioned constraints, the edges between nodes of types code, projects, noter, etc should have limited structure/constraints. It is important to be able to quickly find things later, so the topic nodes act like points of expansion.