email rss
What's coming up in imag (26)
Jun 11, 2017
3 minutes read

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.

What happenend?

  • #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:
    • #953 reintroduced the flock functionality.
    • #954 added more debugging output in the store.
    • #952 Added a consistency-check functionality in libimaglink, so one can check all store entries for link consistency. This is not yet exposed in imag-link, although an issue exists for it.
  • #957 updated the toml-query dependency to 0.2.0 which contains some fixes and more functionality (which was previousely not implemented).
  • #941 Added a libimagentrydatetime for setting time and time-ranges on entries.
  • #959 was a fixup for #941
  • #960 changed libimagmail to use the email crate rather than mailparse.
  • #961 Added missing license headers in some files.
  • #962 was a rewrite of the backend infrastructure of the Store type. 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 category in 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 website right now.

I’m not telling you what I’m doing, but it will get a lot nicer, in my opinion.

Command chaining

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

for example.

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!

Back to posts