blog

Personal blog
git clone git://git.laack.co/blog.git
Log | Files | Refs

ideal-note-taking.md (2242B)


      1 # Ideal Note Taking
      2 
      3 The ideal note taking setup supports the users' preferred note taking modalities. For me these are textual notes, frequently taken in reference to an information source alongside planning for subsequent notes, information sources, and time allotments.   
      4 
      5 Additionally, it must not be built into a text editor. My text editor (vim) is for editing notes, not organizing them.
      6 
      7 I use git for managing persistent, non-binary data, and so my note taking program should work well with git, but it shouldn't have a git integration because that seems beyond the scope of what a note-taking program should do. Similarly, it should be simple to encrypt my notes, but CryFS[1] does this for me, and it is very clearly outside the scope of what a note-taking program should facilitate. 
      8 
      9 ## Specifics
     10 
     11 The above is a high-level, these are the specifics of what I want:
     12 
     13 - Multi-directory support
     14     - I have notes in directories with different threat models, and they should remain logically separated
     15 - Terminal-based
     16 - No built-in backups / synchronization
     17     - I don't want sync functionality because that's what git is for, or network shares, or unison, and these add both complexity and support silly use cases like taking notes from mobile devices
     18 - To-Do tracking
     19     - When taking notes I frequently find related resources or think of related note-taking topic, and I'd like a list of these things.
     20 - Stable and performant
     21     - Apart from mixing concerns and being proprietary, programs like Notion and Obsidian are both unacceptably unstable and slow.
     22 - Scriptability
     23     - It should be easy to write scripts for programmatic invocations of the program. 
     24 - Archiving
     25     - When I take notes I often want to archive sources for future reference, this should be supported by the program.
     26 - Interoperable
     27     - The resulting directory structures should be reasonable for use with SSGs and other tools that have sensible expectations.
     28 
     29 ## Implementation
     30 
     31 I want this to be performant so it must be written in a language that can compile to a sane binary. I don't want to become suicidal from using an object oriented language so I am going to choose Go. 
     32 
     33 # Citations
     34 
     35 [1] - [https://www.cryfs.org/](https://www.cryfs.org/)