This is the 28th 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?

As I said in the last post of this series I was on vacation and therefor there was no article in august.

But wow, since I returned from my vacation, which was lovely, there was a lot change in the imag codebase.

First of all, I pushed the release button for imag 0.3.0 - thanks goes out to all contributors of this version! As I described the state of imag in the release post for 0.3.0, I will only include changes from 0.3.0 to the current master, which is much enough I think.

I will start linking to our own hosting of the code with this blog post, so don’t feel irritated when checking out the links below.

As we had 39 merges from 0.3.0 until now, I will only include the most interesting ones here.

• 764ff6ea96 Integrated the patches that where necessary to get a release out of the master branch when releasing version 0.3.0. That was mainly fixing some Cargo.toml issues and removing some nasty hack from the imag binary source code.
• 513fc6b8d4 Added StoreId::is_in_collection().
• befff96220 Removed the Makefile as cargo can build imag without help now.
• 7b3bf3e31e Changed the dependency specifications between imag dependencies to a path-and-version approach, which might be helpful when installing imag commands. Lets see how this works out for us.
• 4c4de294b5 Reorganized the complete codebase. The crates are now sorted into subdirectories instead of beeing at the top level. Might be interesting for packagers.
• c987130cc1 Ripped out our own “TOML extension” code. All code should now rely on the toml-query crate.
• 279afd1972 Added a CHANGELOG.md file to the repository, so we can have a nice changelog in the next release.
• 609c7fef93 imag-link works with positional arguments on the commandline as of this merge.
• 25ffb60d7b Rewrote the logging backend. Logging can now be configured via the imagrc.toml configuration file.
• 6d1dab3117 Refactored some of the crates which wrapped libimagstore types rather than extending them. Now traits are used to extend them, making everything way more powerful.
• e6d96c9f83 Refactored the error handling of the complete imag codebase. Error handling is now based on the error_chain crate, which offers way more power over our old approach. Using this power will follow slowly.
• ea697a2fa1 Changed the imag-store implementation to use positional arguments.
• 86fae34d0d Rewrote the Store::entries() implementation, which was not based on the store-internal filesystem abstraction. The implementation is not optimal, though considered good enough right now.
• 59feec5f0f Added a functionality to libimagentrymarkdown to be able to extract links from markdown content and add them to the header (via libimagentrylink).
• 374027df3c Added a functionality to use aliases when calling imag. The configuration file has some examples.
• baf8eda571 Optimized the error handling in libimagrt
• 53c7d602eb Optimized the error handling in libimagstore

Still a huge list of changes, right?

What will happen

I really want to focus on developing tools from now on. I am currently thinking about rewriting libimagentryref, as I’m not happy with the current implementation, though I actually used it not that much yet.

I plan on implementing my side-project kairos which I need for implementing imag-habit (which is in progress) and then I want to write imag-calendar and imag-contacts though I have to wait for some good and nice icalendar and vcard crates, still.

Alongside, imag-mail will be one of the places where I will put my focus on. That is mainly because I slightly changed my goals with imag - I feel rather comfortable with the thought of actually implementing the tools myself. So imag-todo will get an imag-native backend at some time, for example. And imag-mail will be a full-fledged mail client (though only for the commandline) at some point in time.

Maybe you think I’m crazy - but I tell you: Some people collect stamps, some make music - I implement personal information management tools in Rust. If you think having a hobby like this is crazy, feel free to move along! If you think that’s awesome, feel free to submit patches, suggest things, start discussions - I’d enjoy some contributions (as in code and as in non-code)!

Back to posts