What's coming up in imag (8)

Another 14 days are over. Here’s my update what’s coming up in imag, the personal information management suite for the commandline.

The past

We had 40 closed issues and pull-requests in the last 14 days, which is really awesome.

I was able to merge 29 pull requests in the last 14 days, which is quite a lot, so I won’t elaborate on all of them (some of them are just small fixes), but let me do a short iteration on the highlights:

  • We implemented Store::get() which returns a None if the entry does not exist (Store::retrieve() implictely creates the entry).
  • The Store::get() functionality was also implemented in the imag store, imag notes and imag tag commands, causing them to fail if you try to list or view non-existent store content.
  • We have a new Hook which gets executed by the store after the store is loaded (so it is called only once, but hooks might do some fancy stuff before the user commands are executed).
  • We have a new crate for writing Date and Time interfaces, which helps parsing user-specified date and time. This crate is not tested yet, though some tests exists within the crate and they succeed.
  • Another crate was introduced for querying the user to provide a store id if he hasn’t already, providing a fuzzy-search interface based on the interactor crate. This crate is not tested yet.
  • The error crate libimagerror provides a way to define custom members and custom code for the error types now, beeing more flexible now.
  • libimagerror also implements Into for the error kinds now, making the code using it even less complex.
  • All crates were rewritten to use the infrastructure provided by libimagerror
  • The binary at bin/imag was rewritten from Bash to Rust.
  • Updates for some dependencies were done
  • Bug fixes, including but not limited to
    • A bug in the config-finding algorithm in libimagrt
    • Bugs in the Hook execution in libimagstore
    • Duplication of data in libimagstore (FileLockEntry and Entry had the StoreId stored, despite the one dereferences to the other)

I also had (finally) some progress with my diary implementation. I guess I may finish it within the next 14 days. I’m serious this time, as the current code works and almost all the things are implemented at the time of writing.

I also have some (little) progress with the bookmark implementation, though I’m not sure whether I will implement this (rather) simple tool by myself or re-use existing solutions. On the one hand the problems are rather simple to solve with the existing imag infradstructure, on the other hand, I don’t want to double work. I guess I will end up implementing it myself anyways, as I consider the (external-)link code part of the infrastructure and I don’t want to depend on an external tool which might be or get unmaintained at some point in future.

I also have a new crate in my pipeline, which helps with Markdown parsing. So for the first step, we will provide Markdown only. But I will wrap this crate libimagentrymarkdown into a more generic one (libimagentrymarkup) to be able to write more backends for it (thinking of textile, asciidoc and so on, maybe by using a pandoc interface) and support other markup languages later on without hassle.

All in all, I really made some progress with the project in the last 14 days. I wrote more than 80 commits in the four days of the GPN last weekend, which was a huge amount of the work in the last two weeks, of course. I hope I can continue my streak.

The future

Well, the future. I don’t really think I can keep up with my latest streak, though I really hope getting the diary implementation done. Bookmarks would be nice as well.

One thing I’m thinking about almost constantly in the back of my head is the DSL implementation for libimagentryfilter. I really want to dig in a little deeper into this. Maybe I can get something working within the next 14 days and if it proves useful I might extend the DSL so I can script the Store with it. Of course, this won’t be a replacement for Rust as implementation language, but might prove useful for smaller scripts and the like? I’m not sure.

I also hope to find some contributors for the project. If you are looking for rust projects to contribute to, feel free to ask me questions or simply try to implement one of the complexity/easy tagged issues on github. Of course you can also ask questions there, I’m happy to answer them!