# What's coming up in imag (13)

Another 14 days - a lot has happened in the repository of the imag codebase, the commandline personal information management suite written in Rust.

Read a summary of the last two weeks here, in the 13th iteration on what’s coming up in imag.

# The past

Lets see what was done in the last 14 days.

## Website, IRC, mailinglist!

First: The important things!

We have a website now! Meet us at imag-pim.org. We also have a git mirror there.

So if you want to contribute to imag but you do not have a github account or you do not want to contribute via github, you can ask me for a repository on the git repository on our website and contribute via mail or via this repository. I will push your patches to github PRs anyways, because of our CI server, but you do not have to interact with github at all. For details, read our CONTRIBUTING file.

We have an IRC channel now! Since 1st of August you can join irc.freenode.net/#imag and talk to us/me directly!

The channel has a bot (nick “imagned”) running which can be used to log discussions. It is a sopel bot, see the page on the “meetings” module for documentation how discussions can be logged.

We have a mailing list now! Since 2nd of August you can join our mailinglist and talk to the imag community via it. Of course, there are few mails posted yet, as this list is really new.

We accept patch mails via this mailinglist as well! Make sure you’ve read the CONTRIBUTING guide before submitting patches.

## Numbers!

We reached the 100 stars on github! Awesome! Thank you all for this! We are reached the 2,500 commits and we reached 400 closed PRs!

## New contributors and integration of the first external tool!

Besides that, we have merged #383, which was a huge one. It implements libimagtodo and imag-todo, using taskwarrior hooks to store references to taskwarrior tasks in the imag store. This allows us to refer to tasks created with taskwarrior from within imag. imag-todo is therefor the first imag module using an external tool to implement the PIM aspect it covers. This is huge! I hope this is the first step into the direction of multiple backends as well.

The PR was created as semester project at Hochschule Furtwangen University and therefor contains commits from several contributors (in alphabetical order):

I did some cleanup in this PR as well as some restructuring. So it was joint work. Because of this, the shortlog tells us the following:

• 52 commits from Mario
• 51 commits from me
• 6 commits from Yasemin
• 4 commits from Sascha
• 2 commits from Roman

Thanks a lot for your contributions!

Other contributors were:

Thank you a lot, too! I also want to thank Julian Ganz and Pascal Hertleif for contributing ideas and participating in discussions on issues.

## PRs merged/closed in the last 14 days

We had a lot of small PRs in the last 14 days, fixing one or two things. This is truely awesome, but the list for PRs is even longer than from last week. I will only add notes to the bigger ones here, I guess I if this trend continues I will start to list only the noteworthy PRs in the future.

But here we go, with the full list of PRs and some of them explained or with an additional note.

• 383 (explained above)
• 594 added an utility to print debugging information while map()ing over Results or Options.
• 595
• 597
• 598
• 599
• 600
• 601 updated the user documentation a bit.
• 604
• 605
• 607
• 608
• 609
• 610 added an EditorView in the libimagentryview library, so one can now view entries with the \$EDITOR.
• 611 fixed a serious locking bug in the libimagstore library.
• 612 added support for --no-color output in libimagrt (so all modules get it automatically).
• 613
• 614 added a TableLister type for libimagentrylist - not tested yet.
• 616
• 617
• 620
• 621
• 622
• 623
• 630
• 631
• 633
• 634
• 636
• 640
• 641 fixed our travis setup and shortened build times from up to 50 minutes down to about 30 minutes.
• 642
• 643 outsourced editor-calling code from libimagrt into the new library libimagentryedit.

## Issues opened and already closed

These issues were opened and are already closed:

# The future

Lets see what the future will bring us.

## Issues opened and not yet closed

First of all we have a bunch of new issues which are not yet closed.

• 602 asks whether we can remove the version part of the StoreId.
• 618
• 628
• 629 asks for an explicit subcommand with imag-todo to import the task export exported data from taskwarrior.
• 637 asks for a feature in libimagref so we can only hash the first N bytes to speed up both hashing and refinding of entries (which is untested btw).
• 644

## Issues reopened

I reopened issues #2, #3, #4 and #5, which ask for a contacts-, calendar-, mail- and wiki-module respectively. Unfortunately, there is no vcard/icalendar crate for rust available. There is vobject, but this is a very basic abstraction over the filetypes. I would need something more complex and powerful, which has a lot capabilities and hides the file format in nice abstractions. For example, if I want to check whether two calendar entries collide somehow, the library should be able to check whether the entries are recurring and whether they collide some time in future … or the contact library should offer a simple interface for querying numbers, mail adresses, adresses, names and so on. With the vobject crate I would need to implement all these things on my own - I really don’t want to do that right now!

Also, I would need a library to read mails from a Maildir for the mail module. There is mailparse - I’m not sure whether it fits my needs, though.

For the wiki part I don’t need anything besides markdown parsing capabilities, and I guess I already have them. I would implement the wiki module with the libimagref library, which can then be used to ref to existing wikis such as vimwiki. I’m not sure whether this is the proper way to do this, though.

## Other things

Vacation! I will be on vacation from Saturday August 13th until Tuesday, August 23th. I will be at the Summerbreeze Heavy Metal Festival (feel free to meet me there!) from Tuesday, August 16th until Sunday, August 21th, so there will be no commits in this timerange (at least not from me) and of course no merges.

Because of that I’m pretty sure that the next iteration on imag will be a short one - but well, I guess I deserve a break from my bachelors thesis which is almost finished.

And also because of this, I do not have any plans for the next 14 days. Lets see what comes up… lets hope something great! Maybe some new contributors…