Add post: Whats comping up in imag (41)

1 files changed, 116 insertions, 0 deletions

diff --git a/content/blog/2019-12-08-what-s-coming-up-in-imag-41.md b/content/blog/2019-12-08-what-s-coming-up-in-imag-41.md
new file mode 100644
index 0000000..0cca17c
--- /dev/null
+++ b/content/blog/2019-12-08-what-s-coming-up-in-imag-41.md
@@ -0,0 +1,116 @@
+---
+title: "What's coming up in imag (41)"
+date: "2019-12-08T14:45:40"
+tags: [ "linux", " open source", " programming", " rust", " software", " tools", " imag" ]
+---
+
+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](https://imag-pim.org).
+
+<!-- more -->
+
+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](https://git.imag-pim.org/imag/commit/?id=598b6ec9a6f8eb0b878f924df3ebe10ca27d68b0)
+  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](https://git.imag-pim.org/imag/commit/?id=d8df96ad1fa99940a07a86cebccaab61b6d1bff1)
+  Added a new "core" command: imag-create
+* [712eda074](https://git.imag-pim.org/imag/commit/?id=712eda074d97b400cb0c35018e72547d5073b616)
+  Added libimagcalendar, a library for handing calendar data.
+* [b7e996ccf](https://git.imag-pim.org/imag/commit/?id=b7e996ccfe148dc002a24697ce1bb299ee8d1725)
+  Added a new "domain" tool: imag-calendar
+* [7a0654465](https://git.imag-pim.org/imag/commit/?id=7a0654465413fb7e447d4a7e80a6bc24adebf605)
+  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](https://leon.is.currently.online/master/) - Thanks a
+  lot Leon!
+* [cc6a833ab](https://git.imag-pim.org/imag/commit/?id=cc6a833ab69c8481daa9794c3fb152acf0a22721)
+  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](https://git.imag-pim.org/imag/commit/?id=c67f0bbd4bd2bc225cb4d7663d468fa5600408f7)
+  Included changes in imag-calendar to not call exit() in the code but propagate
+  errors to main().
+* [fa7e8cc6b](https://git.imag-pim.org/imag/commit/?id=fa7e8cc6b41ad07166655aa024ced20239e3dea9)
+  Included changes in imag-bookmark to not call exit() in the code but propagate
+  errors to main().
+* [1f858cf4b](https://git.imag-pim.org/imag/commit/?id=1f858cf4bd88c9f674ca1994c38a12a826b3257e)
+  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](https://git.imag-pim.org/imag/commit/?id=7b6e5eafbaadd1cd898cd3cf78b7559b98d7af81)
+  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](https://git.imag-pim.org/imag/commit/?id=ead9438c412c6f14fc6f3d77fb88ca40a7634452)
+  Rewrote libimagtodo and imag-todo completely.
+* [99fedd5ab](https://git.imag-pim.org/imag/commit/?id=99fedd5abd77dd5ea8da5806667fe53680acc879)
+  Added taskwarrior importing for imag-todo
+* [1a25bd2da](https://git.imag-pim.org/imag/commit/?id=1a25bd2da4dafc0768a41b8fe4539dc7e3edb194)
+  Added a filtering option to imag-tag
+
+Another big chunk of changes was contributed by
+[Philipp Krones](https://github.com/flip1995), 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...
+