This is the 41th iteration on what happened in the last four weeks in the imag project, the text based personal information management suite for the commandline.
Almost half a year since the last update. I could definitively do better, I know. But a lot of stuff has happened. I have a real job now, am not a student anymore. That, of course, takes a lot of time.
Anyways, lets get started with what happened in imag in the last months. Of course, I could just dump the git log, but this would just bore you all. That’s why I list only the stuff that’s interesting to the user here.
- 598b6ec9a Removed the “where-clause-filtering” in imag-ids as well as the “in-collection” filtering. There’s a “imag-id-in-collection” core command now that does the job.
- d8df96ad1 Added a new “core” command: imag-create
- 712eda074 Added libimagcalendar, a library for handing calendar data.
- b7e996ccf Added a new “domain” tool: imag-calendar
- 7a0654465 Improved the story around building imag commands as a subcommand to the “imag” binary itself. First of all this was done to be able to generate autocompletion scripts using clap, but this also improves the story around building imag as one big binary rather than many small(ish) binaries. This was contributed by Leon - Thanks a lot Leon!
- cc6a833ab Improved the story on error handling in all “core” commands in imag: The binaries do not call exit() anymore, but propagate errors up to the main() function where they are returned. This results in way less boilerplate with error handling in the implementations of the commands, as well as a cleaner shutdown if an error happens, because destructors are actually called (and the program does not simply kill itself).
- c67f0bbd4 Included changes in imag-calendar to not call exit() in the code but propagate errors to main().
- fa7e8cc6b Included changes in imag-bookmark to not call exit() in the code but propagate errors to main().
- 1f858cf4b Adds an option to imag-link to create a directed link. Before that, links between entries were unidirectional. Now there’s a way for creating directed links.
- 7b6e5eafb Added a test infrastructure for testing the UI of imag. This is a big step forward towards a UI that is more concise and reasonable.
- ead9438c4 Rewrote libimagtodo and imag-todo completely.
- 99fedd5ab Added taskwarrior importing for imag-todo
- 1a25bd2da Added a filtering option to imag-tag
Another big chunk of changes was contributed by Philipp Krones, who contributed a lot of clippy fixes. Thank you a lot Philipp!
What’s happening right now
I’m in the CLI-Working-Group where we collaborate on the CLI ecosystem. I am participating in discussions to help improving the ecosystem around CLI applications. That, of course, takes some of my time, but I’d say it’s a good investment. More on that subject will be on my personal blog, if I can manage to write everything up.
In the imag ecosystem, I’m still working towards imag 0.10.0. I hope I can publish the release before January 2020. Well,… lets see.
After the 0.10.0 release, I will start focusing on two subjects: imag-mail and the TUI infrastructure that is necessary for implementing a TUI for imag.
First things first, imag-mail. I thought a lot about whether to implement a complete MUA or just a tool to implement a tracking functionality for mails and for including mails into the imag ecosystem. I came to the conclusion that if I want to write a MUA (either a CLI one or a TUI one), I always need the latter. So, the imag-mail module will be a two-component module: One part of it being rather “low-level” for tracking mails (as in Maildir for the first part) and the second one implementing MUA-like functionality (CLI) on top of that.
Of course, the next step is to implement a MUA with a Terminal User Interface on top of that. For that, I need some more stuff in the land of TUI crates.
Right now, the TUI crate I want to use (cursive, of course) does lack some things I want to implement before I want to start implementing a TUI for imag. The TUI will be a fully-integrated imag, so no individual modules anymore but one binary that includes all tools in one TUI. Maybe parts will be selectable for inclusion/exclusion at compiletime, but there won’t be a way to load/unload parts during runtime. I spend some time thinking about whether such a thing would be possbible and I came to the conclusion that the problem, while interesting, is not worth the hassle.
I also am thinking a lot about how to structure a TUI crate for imag, which would of course contain all imag tools and thus be composed of several modules within imag. A concept on how I want to setup the TUI interface and on how to structure the whole thing is in my pipeline and will probably end up in another post.
For so long, that’s where the journey goes…