can tool is built from separate commands. The
can binary itself should be a thin wrapper which runs another binary in the form
can-<command name>. For example, if I run
can new, the
can binary should search for
can-new and run it. This is similar to how the
git command works.
This is beneficial for multiple reasons. Development on commands can stay focused and only include what is strictly necessary for that command, while vital shared libraries can still be used across multiple can still be used across multiple commands. Development is also extremely flexible. New commands can experiment and persue different tooling or even different languages without needing older commands to be changed at the same time. And, again similar to
git, third parties can supply new commands easily without needing the blessing of the original creator or needing to dive into the deep nitty gritty, even building tooling on the other commands available to end users using the 'plumbing/porcelain' model.
The commands shown here are all commands, including internal commands. Those closer to the top are more likely to be used by the end-user.
|can-status||report the current state of the writing folder|
|can-add||add notes from the writing folder into the notebook|
|can-new||create a new writing-folder containing a notebook|
|can-ast-at||given an address, find the AST of a note|
|can-md||convert from markdown to can's internal AST format|
|can-address||find the address of a particular AST|
|can-note-graph||construct a list of addressed notes from the writing folder|