Another exciting two weeks! This is the fourth iteration on what's coming up in imag, my personal information management suite for the commandline.

And we had an awesome bunch of merges in the last 14 days!

Editors everywhere!

We now have a utility function in the runtime library for calling the $EDITOR, which either uses the editor specified by the commandline arguments, or the configuration, or the $EDITOR variable from the environment.

This was implemented by a friend of mine who wants to learn rust as well. Thanks a lot!

Warnings? No, Errors!

We got two patches merged (one for the store library, one for the runtime library) which turned warnings of a certain kind into hard errors and prevent compilation. I take this as “We get more stable”.

More debug output!

A whole bunch of merges were done to enhance the debug output in a lot of cases. For example, the Store object implements Debug now, which means that debugging the store is way simpler than before.

Bugfixes!

Remember me writing about how few bugs we had by now? Well... we had some but did not find them. We merged a bunch of bugfix-pull-requests in the first part of the last 14 days. Most of them were rather simple bugs (one was even a one-character-was-wrong bugfix) but nevertheless critical.

Readusall!

I added one readme file for each crate in the project, so people can see what are the libraries supposed to do. Awesome, isn't it?

New Issues!

I've added a whole bunch of issues in the last 14 days, and all of them are tagged with either complexity/easy, complexity/medium or complexity/high as far as I can remember. So if you want to have a look what's going on and maybe help with some pull requests, the ideas are already there!

Here's a short iteration of the issues I opened...

• #282 - libimagrt config returns ConfigNotFound even if it was a Parser error. The runtime library returns a RuntimeErrorType::ConfigNotFound even when there was a parser error. This has to be fixed. Complexity: Easy.
• #284 - imag-tag should use libimagtag::exec::exec_cli_for_entry(). The imag-tag module does not yet use the libimagtag functionality for executing the commandline specification via the library and instead reimplements this functionality. Complexity: Easy.
• #294 - Store should automatically fallback to latest version of entry. The libimagstore::store::Store type does only load the entry specified. By using the libimagstore::storeid::StoreId type and the generator macro for generating these objects, we enforce the version of the entry to be present. What we do not do is to allow the version part to be optional (when building the entry path from a commandline specification). If we would allow this, the store would need to fall back onto the latest version of the entry which is currently available. The store does not do this at the moment, but I think this would be a nice feature, actually. Complexity: High.
• #297 - Library for extracting links from content. There has to be a markup library which allows us to extract links from a Markup document such as Markdown, TexTile and so on. This library and libimaglink could then be used to create the header links via some store hooks. Complexity: medium / maybe high.
• #298 - Hook: Verify that all linked entries exist. That's a rather simple one: We need to check whether all links from a header are actually existing files in the store. We want to do this as hook and we want the hook to be configurable to either deny entry changes or just print warnings.
• #299 - Check whether we want ot use Cow in our APIs. Another rather simple one: We want to check whether it would be beneficial if we'd use Cow in our internal APIs. Mostly for String types, but maybe also for other types as well. Complexity: Easy.
• #300 - Rewrite libimaglink – external linking. The external linking library module has to be rewritten. See the issue for more information. Complexity: Medium.
• #301 - module: Bookmarks. We want to introduce the bookmarking module. Complexity: Easy.
• #302 - Store Hook Aspect configuration: Setting do deny mutable hooks. We want to be able to configure hook aspects to deny mutable hooks. This is mainly a security-related task and would be a nice to have. Complexity: Medium.
• #303 - Make store hooks be executed in parallel if possible. We want to alter the hook execution algorithm to execute hooks in parallel if possible. Complexity: High.
• #304 - imag-view: libimagentryview has to be written. We want to extract the viewing functionality from imag-view and add some more functionality to it. This should be put into a new library libimagentryview. Actually there's someone working on this. Complexity: Easy.
• #306 - module imag-stat. Another nice-to-have: A module for getting some stats/diagnostics about the store. Complexity: Medium.
• #307 - libimaglink: XDG-open for external links. We want to add a feature in libimaglink to open external links via xdg-open. Complexity: Easy, can only be started after #300 was merged.
• #308 - Logging: Print file and line on debug!(). We should alter our logger backend implementation to print file and line on each debug!() log call as well. Complexity: Easy. This Issue was closed at the time of publishing this blog article.
• #312 - Rename: libimaglink –> libimagentrylink. We should rename this library for more consisteny. Complexity: Easy.
• #313 - Rename: libimagtag –> libimagentrytag. We should rename this library for more consisteny. Complexity: Easy.
• #314 - Remove warnings from libimagutil. We should remove the build-time warnings from this library. Complexity: Easy.
• #315 - Convert TOML destructuring into toml::Value::lookup(). As the TOML crate supports Value::lookup() to lookup values at a specific path, we can use this functionality to replace a lot of boilerplate code which simply destructs TOML objects. Complexity: Medium, because a lot of code has to be checked and altered. The changes themselves might not be that complex.
• #316 - module: weather. I added this issue for tracking of the implementation of the weather module. Yes, we plan a weather module for imag, see the linked issue what I expect such a module to do. Complexity: Easy.

This list could be seen as a cry for contributors! At least there is now a list available what has to be done and with some complexity level attached - contributors can now see where to start!

Side-Project: task-hookrs

This is a little side-project which I started. It aims to implement a crate for interacting with taskwarrior, so you can export tasks from taskwarrior and import them into your rust program. Of course I'm writing this so I can use it in imag to implement the todo module by using taskwarrior as todo manager and interface with it through taskwarrior hooks and my task-hookrs crate.

In the last 14 days I got some important points working: Deserializing and Serializing are already working and so is importing from a Read. Exporting is on its way.

Some things I didn't implement yet is support for the id and urgency fields and annotations are missing as well, but I guess these are really simple to implement as well.

I'm really looking forward to get this crate working in the next days and I'm starting to wonder whether I should put in on crates.io and how this whole process works.

What's coming up

As always, I want to close this article with a prospect. I got less stuff done than I expected in the last 14 days:

$ git diff --shortstat $(git log --since=14days --format=%H | tail -n 1)
56 files changed, 1193 insertions(+), 86 deletions(-)

I'd love to get some more progress in the next 14 days, though I cannot guarantee it, as I have to write a bachelors thesis and as I have to do some other important things as well. I really hope I can get the diary module ready and merged within the next days and maybe I can start implementing the bookmark manager then (after I solved #300). As this is not that complicated besides the #300 which has to be merged first, I might get started with the todo module as well. I really hope so.

tags: #linux #open source #programming #rust #software #tools #imag