It came up in conversation that managing the filepath of the notes folder is tedious. In general the relationship between the executable source code location and the notes content folder is undefined. Storage of file content is also ambiguous: some are using new files for new note files, while others are using text files as databases for all notes. This is an attempt to answer that problem. I am unsure if this change is contingent on my our project. I am also unsure if it relies on the changes I suggested we make to the frontend.
Everything is A File
This is a tagline used by the Unix community to articulate their view of files. Any container that persists in memory independently and stores data is file. Therefore, we should handle notes as files. OS operations to delete and add files are much faster than our operations to delete and add text to files (with manual headers). Information about the location of the notes folder is also persistent and independent. Therefore, the configuration of the notes system should be a file, call it notes.config
Configuration is Key To Usability
We get free user customization by providing the user with an open source and well-documented config. The file would contain a filepath to notes folder in memory. It could be absolute or relative. When our script runs it could look in the home directory for the config and read its notes_path attribute for the path of the notes file. Then we can do all operations on notes in that path. We could also have a notes_history attribute that points to some database file storing change logs to these files. The script could read and write to that database when searching in modification history and making changes
Changing Install
With this and the CLT changes it would be possible to make our project an actually portable tool. We would need to write an install script that sets up the config file with the default and builds our source as a binary executable. But at this point it might be possible to distribute our on a package repository. If we wrote a ton of tests and wrote good documentation maybe one day people could run brew install noteworthy :))
Introduction
It came up in conversation that managing the filepath of the
notesfolder is tedious. In general the relationship between the executable source code location and the notes content folder is undefined. Storage of file content is also ambiguous: some are using new files for new note files, while others are using text files as databases for all notes. This is an attempt to answer that problem. I am unsure if this change is contingent on my our project. I am also unsure if it relies on the changes I suggested we make to the frontend.Everything is A File
This is a tagline used by the Unix community to articulate their view of files. Any container that persists in memory independently and stores data is file. Therefore, we should handle notes as files. OS operations to delete and add files are much faster than our operations to delete and add text to files (with manual headers). Information about the location of the notes folder is also persistent and independent. Therefore, the configuration of the notes system should be a file, call it
notes.configConfiguration is Key To Usability
We get free user customization by providing the user with an open source and well-documented
config. The file would contain a filepath tonotesfolder in memory. It could be absolute or relative. When our script runs it could look in the home directory for theconfigand read itsnotes_pathattribute for the path of the notes file. Then we can do all operations on notes in that path. We could also have anotes_historyattribute that points to some database file storing change logs to these files. The script could read and write to that database when searching in modification history and making changesChanging Install
With this and the CLT changes it would be possible to make our project an actually portable tool. We would need to write an install script that sets up the config file with the default and builds our source as a binary executable. But at this point it might be possible to distribute our on a package repository. If we wrote a ton of tests and wrote good documentation maybe one day people could run
brew install noteworthy:))