notcoal, filters not made from (char)coal / initial tagging system

[eaon]

Hi notmuch list,

I built a thing that maybe other people might be interested in:

https://crates.io/crates/notcoal "notmuch filters, not made from (char)coal"

notcoal provides both a library as well as a standalone binary. The latter can
be used as an "initial tagging" system, the former may be integrated into a
bigger e-mail client making use of https://crates.io/crates/notmuch

If you have cargo set up already you can install it quite easily with:

$ cargo install notcoal --features=standalone

Cheers,
eaon

[Kim ALLAMANDOLA]

Hi,
being a new notmuch user (using it since around an year) I have a small,
obscenely written, badly shaped, mixed language collection of homegrown
scripts to automate my message handling / mail-based workflow.

Most part are zsh wrappers to autotag (autorefile for now is done by
IMAPFilter) and support manual delete/refile messages, a small part in
an initial state is automation in the sense of extracting mime
attachments (via uudeview) like periodic invoices and properly archive,
renaming attachments etc in a personal docs taxonomy so having a more
well-shaped and ready out-of-the box solution is really welcomed!

The only part I do not like too much is the choice of json instead of
something, *for me*, less ugly to write/read, less error-prone and more
flexible like simple plain guile (GNU embeddable, lightweight scheme
dialect).

The re-write of notmuch in Rust, well... it's outside my scope since I
use it as a "final product", I'm in general favourable to ditch "myths"
like C and C++ and Java, ... for more comfortable languages but for me
nor Rust nor Go really fell in that category, IMO the best paths is
rediscover lisp/scheme languages even if I know that in some cases are
harder to use (while far easier in other) however as said before I'm
only a user so I have to thanks all notmuch and notmuch-related devs
for their wonderful works, I'll try Rust port anyway :-)

-- Kim

[David Bremner]

Post by Kim ALLAMANDOLA
The only part I do not like too much is the choice of json instead of
something, *for me*, less ugly to write/read, less error-prone and more
flexible like simple plain guile (GNU embeddable, lightweight scheme

I don't know the context of this statement, but "notmuch show" and "notmuch
search" support --format=sexp.

[Kim ALLAMANDOLA]

Hi,

Post by David Bremner
I don't know the context of this statement, but "notmuch show" and
"notmuch search" support --format=sexp.

Oh, nice, I do not know that, thanks. It can be nice for some macro
automation, I'll try it!

-- Kim

[eaon]

Hi Kim,

… so having a more well-shaped and ready out-of-the box solution is really
welcomed!

Thanks! Yeah, my organically grown python script really annoyed me too, but the
segfault problems just pushed me over the edge to try and make something
that may be useful to others too. There's still a couple features missing to
have it be as useful as I'd like it to be, but it's a start. I'm certainly open
to feedback!

The only part I do not like too much is the choice of json instead of
something, *for me*, less ugly to write/read, less error-prone and more
flexible like simple plain guile (GNU embeddable, lightweight scheme
dialect).

I get it. The choice really mostly came down to https://serde.rs/ because it is
such a nice library and very easy to use. It does support other data formats but
I haven't tried any of them. So yeah, I can look into making the input format
more flexible for sure.

The re-write of notmuch in Rust […]

Ah, misunderstanding there, maybe. notmuch-rs is not a rewrite or port, it's
just an interface/bindings for libnotmuch. A couple people have attempted that
before, I just used the one that someone seemed to actively try to maintain and
take patches for.

As for language preferences, Rust is really just something I got into recently,
and it's fun, the tooling around it is cool even though the centralisation of
some of the infrastructure is something that annoys me a bit. But that is made
up by the open welcoming community.

eaon

[Kim ALLAMANDOLA]

Hi,

There's still a couple features missing to have it be as useful as I'd
like it to be, but it's a start. I'm certainly open to feedback!

For me it's already really nice, essentially overlap some afew features
in a more flexible/extendable manner. My personal automation add mostly
physical message manipulation that can be generalized only to a certain
extent: for instance I have a script that look for mail from my mobile
carrier invoices and automatically extract attached pdf to a specific
taxonomy with a name generated from the invoice number and month
pdfgrep-ed from the pdf itself, same for home ISP, another that look for
"invoice notification" by EDF (home electricity provider) that do not
offer invoices sent as attachments and so add a reminder to manually
download them from EDF's portal in my agenda plus adding "periodic"
self-reading consumption communication schedule/deadline, they also take
care of archiving (mark unread) messages, delete some messages after a
certain amount of time, "snooze" others (mark read upon arrival and at a
certain point in time mark unread again), forge&send new message as a
poor man's agenda notification when I'm not on my desktop (like on
mobile)... I'll plan to add a cross-check from invoices to bank movements
(ledger) to send a remainder if after a certain amount of time an
invoice does not appear to be paid from my bank etc.

Many of those function have some common points and can be cleaned up,
unified in a single language (actually are a mix of zsh scripts, hy
scripts, python scripts, horribly interconnect in "chain-calls") and
inserted in a single library to create a generic tool flexible enough
to be useful for others but they are essentially a sort of chaotic,
primitive PIM suite around an email-centric workflow, the opposite
of notmuch philosophy I suspect. Also many functionality are actually
crude wrappers around other tools that can't be cleanly integrated in
a new one (like IMAPFilter, alot, uudeview, pdfgrep, pdftotext, ledger,
...) so it's more than a simple cleanup and translation...

The re-write of notmuch in Rust […]

Ah, misunderstanding there, maybe. notmuch-rs is not a rewrite or
port, it's just an interface/bindings for libnotmuch.

Ops... Honestly I look only at notcoal page ignoring the rest leaving
a remainder for next weekend to give a real try :-(

-- Kim