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 theimag
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 (vialibimagentrylink
). - 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)!