I personally really like that himalaya is command line oriented, rather than TUI oriented. There are lots of TUI email clients out there; it's a crowded space. Having a tool like this one, though, that works much like git or any other CLI tool, is much easier to compose with those tools, much easier to build emacs/vim/VS Code plugins around, much simpler, and much easier to use.
The CLI is not (anymore) the core crate of the Himalaya project. The core crate is the library, and the CLI is "just" one interface, one implementation. The aim of the library is to allow people to build their own interface without caring about how to send an email or how to download attachments. I would like to propose default interfaces at minima (a CLI, a TUI, a GUI, a web server and some plugins (Vim, Emacs etc)). All those interfaces will be in their own crate, so the CLI will remain the way it is now :)
On a bigger scale, Pimalaya (the Mother project) aims to gather tools like Himalaya (lib + interfaces) related to Personal Information Manager, because IMHO this domain really needs a good refresh. Rust looks like the perfect language for this refresh: robust, performant, cross platform compatible with a wonderful tooling/documentation and a growing community!
Pitching in here:
I think it would be quite simple to build an RPC-based TUI on top of the CLI - seeing as we have the JSON output format and everything. I agree that a default TUI implementation would be nice, but doing it by composition of the Himalaya CLI would really showcase the flexibility, like ~skin mentions.
Agreed also, it is how the Vim and the Emacs plugins work actually. We need to dig a bit this point to see how easy a TUI can integrate with the CLI. Let's say the lib gives more freedom and flexibility, but costs more to develop than reusing the CLI.
A good example is the logs, by using the CLI you loose all the trace, warn, debug and info logs. Whereas if you use the library you can plug logs for example to a specific windows or frame of a GUI.
Many tools are built on top of a CLI, because it's easy to do and because it's an easy interface to test things out on. That said, the way Himalaya is written, plugging directly into the rust library wouldn't do anybody any harm either. It would certainly be more cross-platform; on Windows if you have to build on top of a CLI you need to package everything together. Statically linking everything together is a great way to package it together easily.
It would certainly be more cross-platform
Totally, another good point for the lib over the CLI.