summaryrefslogtreecommitdiffstats
path: root/content/blog/2019-12-08-what-s-coming-up-in-imag-41.md
blob: 0cca17c6e9ef8ff7e7f2faf7b10375b094aa73b7 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
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...