What's coming up in imag (12)
Another 14 days in imag, the personal information management suite for the commandline – awesome!
We got a huge bunch of PRs merged in this period, which is awesome! Read more about it in this 12th iteration on what's coming up in imag!
The past
We got PRs of three contributors merged in the last 14 days. Thank you very much, Kai Sickeler, Gavin Thomas Claugus and LeRoyce Pearson!
Also, we
- hit the 80 stars-mark on 16th of July
- hit the 90 stars-mark on 25th of July
- hit the 2200 commits-mark on 25th of July
This is so awesome!
PRs merged in the last 14 days
As the number of PRs was rather high in the last 14 days, I just explain the most important ones here, leaving the others uncommented. If one wants to dig deeper, the PR description or title should suffice.
- 522 adds the
implementation for
imag-bookmark– the frontend for libimagbookmark, which is implemented in #521. 301 was closed. - 514 was closed for 569, which superceeded it.
- 542
- 543
- 544
- 545
- 546 adds more levels (more details) in the hook execution error wrapping
- 547
- 548 fixes the
MutableHookDataAccessorto also executeStoreIdAccessors - 549
- 535 added unit support for
imag-counter. - 550 fixes the example
imagrcfile. - 551
- 552 removes some trait
bounds from the hook traits, as they do not have to be
Sync. - 553 adds non-aborting
support for hook errors. This means that a hook can return with an error
which does not abort the store action it was called for. For example if a
Store::create()call invokes a hook which fails somehow, the error can be marked to not abort theStore::create()call. By default, hook execution errors are aborting. - 554
- 555
- 557 merged commits so the store does not get created implicitely anymore.
- 558
- 559 refactored
imag-view. - 561 adds a feature to the
store which can be opt-in'ed at compiletime which gives the possibility to
verify the store contents. This is implemented in the
imag-storebinary, which now has a subcommand to verify the store. - 562
- 563
- 564 fixed some issues with
the
imagbinary behaviour which was not very convenient at the time. - 567
- 568
- 570 (closed unmerged, superceeded by 571)
- 571 added support for config override the configuration via the commandline.
- 573
- 575
- 578,
579,
580,
581,
582,
583 and
584 fixed the missing
deny()blocks – warnings will now be treated as errors and abort compilation. - 586
- 587
- 588 refactored
libimagcountera bit. - 589 added a meta-crate for
building the documentation of all
libimag*crates in one step. - 592 made travis-ci silent.
PRs opened in the last 14 days and not yet closed
The future
Lets see what the future brings us...
Issues opened and already closed
The following issues were opened in the last 14 days but are already closed.
- 556 asked for a rewrite of
imag-view. - 560 mentioned an issue
with the info-output which wasn't shown if
--verbosewas passed. - 565 requested support for overriding the configuration via the commandline.
- 572 mentions a bug that
imag-viewoverrides--versionin an unexpected way. - 574 mentions an
inconvenience with the location of the
imagrcfile. - 585 was mentioned by
Kai – some small enhancements can be
made to
libimagcounter.
Issues opened and not yet closed
The following issues were opened in the last 14 days. I might have missed some in this list, but here are the important ones:
- 539 is a question whether
we want the clap feature “suggestions” in imag and whether we want to create
a wrapper crate for this or use the more noisy variant and enable it in
every single
Cargo.toml - 541 is a RFC for a
imag-replcommand. Would be a nice-to-have, I guess. I'm not sure about this, though. - 566 requests a switch to
clapfor theimagbinary. - 576 mentions that we use
unwrap()quite to often. - 577 mentions that we might
implement a curses frontend for
imag-view. - 590 asks for
libimagnotificationwhich should usenotify-rustto create a notification utility library. - 591 asks for an update of the README.
Other things
I'm still working on the git backend implementation and I really hope I can get some progress. Right now I'm having a weird panic because of an RW-Lock. I don't know why, though, and I really hope I can solve this quickly. I fail finding/seeing the issue, though.
tags: #linux #open source #programming #rust #software #tools #imag