This is the 26th iteration on what happened in the last four weeks in the imag project, the text based personal information management suite for the commandline.
imag is a personal information management suite for the commandline. Its target audience are commandline- and power-users. It does not reimplement personal information management (PIM) aspects, but re-uses existing tools and standards to be an addition to an existing workflow, so one does not have to learn a new tool before beeing productive again. Some simple PIM aspects are implemented as imag modules, though. It gives the user the power to connect data from different existing tools and add meta-information to these connections, so one can do data-mining on PIM data.
- #946 Here we reverted #854, which was the “Remove stuff for focus shift”. So basically, we resetted the state to before I decided to go full-on the Ruby bindings (modulo other fixups of course). This is because we are not focussing on the Ruby bindings anymore (as already discussed in the last iteration of this blog series.
- #951 In this PR we removed the hook support. It actually consistet of this initial PR as well as three sub-PRs which (partially) re-introduced the functionality from the removed hooks:
0.2.0which contains some fixes and more functionality (which was previousely not implemented).
libimagentrydatetimefor setting time and time-ranges on entries.
- #959 was a fixup for #941
libimagmailto use the
- #961 Added missing license headers in some files.
- #962 was a rewrite of the
backend infrastructure of the
Storetype. Before, the store backend (the part that actually spoke to the filesystem) was inserted into the code via a compiletime-option. This option was whether the store was compiled for using or for testing. In the testing case, the store was compiled with an in-memory backend, so the tests didn’t hit the metal. Now, the backend is set during runtime via dependency injection, which gives us more flexibility. For more information consult the commit, which contains a detailed explanation why this change was necessary.
- #943 introduced a library
for having a
categoryin each entry. This might become helpful from time to time.
So, the biggest change was the switch back to the “we implement it in Rust” idea and the move from Ruby.
What will happen
As of the time of writing, we have eight issues left until the 0.3.0 release is ready. This is a huge one and I am more than happy when we finally release. Hopefully I can do this within the next two weeks or something. A blog post will be written, of course.
Quietly, I’m rewriting the imag-pim.org website right now.
I’m not telling you what I’m doing, but it will get a lot nicer, in my opinion.
One big thing I really want to tackle right now is imag command chaining as described in #956.
This is basically an idea how to redesign the store and its interface to be able to write chainable imag commands:
imag entry new --at /music/metal | \ imag entry add --at /music/trance | \ imag filter --name-glob metal --do 'imag tag +metal' | \ imag filter --name-glob trance --do 'imag tag +trance' | \ imag category add "music" | \ imag edit | \ imag persist
I’m currently figuring out the semantics and how to design this properly.
If you want to participate in the discussion, please don’t hesitate to post in the github issue!