pigeon-rs VS clap-rs

I'm still fine with Thunderbird as a MUA (more or less). Using number 1 and 4 as shortcuts to mark an email as "todo" or "urgent". Invitation to appointments (ics file format) can be accepted as well. Integration of contacts is a paint point though.

For email automation I have written a lightweight CLI in Rust [1] which supports MIME and SMTP. I'm currently integrating sendmail's capabilities as well, so that it can be used both as a MUA (message user agent) and MTA (mail transfer agent). Cargo's feature flags will hopefully give you a UNIX-like experience (only compile the features you want to use).

In general, I share your sentiment. Email is still the best protocol to contact people outside of your organization. It's a pitty that encrypted email somehow haven't prevailed. The matrix protocol might be better suited for standardized and encrypted communication.

I would argue that every citizen should get a state-issued email address which then can be used for official communication with public authorities (signing and encrypting being a prerequisite). In Germany, you still get so much paper via regular mail. Even the Covid-19 quarantine order is send by post. It only arrives when quarantine is already over. (Admittedly, you get this order by phone, too, and they are asking for your email address.)

[1] https://github.com/quambene/pigeon-rs

Pigeon is a command line tool for cheap and efficient email automation written in Rust.

That's it. Pigeon has some more handy features which you can check out on github and it is on crates.io as well.

We will be using the library for Clap - A simple-to-use, efficient, and full-featured library for parsing command line arguments and subcommands.

I recently came across this question (and associated answer) on the clap repository. The answer given is a good one. But I wanted to expand with my own findings and practices, which spurred the motivation for this post.

We can also use tuple-like struct syntax and named-field struct syntax for enum variants within our enum; this is because unlike in other OOP languages, Rust enums are actually sum types. You can read more about how powerful Rust enums are in another article we wrote here. You can have optional arguments by simply wrapping the types in Option, but if you want to add a flag to a command you can use bool, since clap recognises that flags are either there or not there. Let's have a look at what this might look like:

I began by developing a wrapper for the CurseForge API, which turned out to be a lengthy and challenging process but constituted the bulk of the work. Next, I coded the CLI, which was relatively straightforward. Instead of using the clap crate, a Rust tool for generating CLIs, I opted for the following line of code:

By this time I had already gotten tired of parsing arguments by myself and had looked for something to help with that. I found a really dang good argument parsing library called clap. What makes it so cool is it's largely declarative for common uses. You simply mark up a struct with attributes, and the parser automatically generates the usage and all the argument parsing code.

How CLI arguments are handled (using clap).

Is this just referring to wrapping based on the terminal width? That is supported with the wrap_help feature though I have been considering making it a default feature.

CLI, use Clap. If you want to get fancy, use Tui.

As our CLI is getting more complex, we'll use the clap crate to parse the command line arguments.