Hi,

the reason I am thinking about Himayala is that it looks like it
is the first CLI email client which takes into account current
world, where everybody has multiple IMAP accounts (or most of
us). With mutt (my current CLI client) support for multiple IMAP
accounts is wandering somewhere between non-existent and
hackish. Himayala at least seems to have a concept of
account. However, it would be nice to use it more.

First problem I have hit on is that I don't know how to move a
message between two accounts. It would probably require to
extend the defnition of folder description to something more
convoluted. Something like this?

    himalaya -a work -f INBOX move local:Junk 321323

Not sure what all could be legal characters in a folder name
(sr.ht shown me that both ~ and / could be part of the email
name), so what could be used as a separator.

What about this?

Best,

Matěj

-- 
https://matej.ceplovi.cz/blog/, @mcepl@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
And religious texts are a bit like software standards, the
interpretation is always the tricky and complicated bit.
    -- Alan Cox

> First problem I have hit on is that I don't know how to move a
> message between two accounts.

Between local and remote, this of course makes sense, but I'm not quite 
sure how this would generalize to transfers between two remote accounts. 
Does IMAP even support such a transaction (other than forwarding?)

> First problem I have hit on is that I don't know how to move a message
> between two accounts.

Instinctively I would go for sth like:

$ himalaya read 42 --account source --raw | himalaya save --account target

> It would probably require to extend the defnition of folder
> description to something more convoluted. Something like this?
> 
> himalaya -a work -f INBOX move local:Junk 321323

I like your concept, but I am afraid it goes against the philosophy of
the tool. I would like to keep the API as simple as possible so you can
compose easily. Regarding your use case:

- you know how to read a raw email

- you know how to save an email in a folder

- you know how to delete an email

So technically you can copy/move emails between accounts.

On 2023-03-24, 08:23 GMT, Clément DOUIN wrote:
> Instinctively I would go for sth like:
> 
> $ himalaya read 42 --account source --raw | himalaya save --account target
  
Do you expect himalaya to be used by a human user for their mail
needs (something like MH Mail NG), or is it meant to be just
shell API for real applications to use (like what your vim and
Emacs plugins do)?
  
It seems that himalaya has too much sophistication and user
interface for the latter, but for example this functionality
would be good for the former. So, which is it?
  
Best,
  
Matěj

-- 
https://matej.ceplovi.cz/blog/, @mcepl@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
Whenever Christ our life is revealed, then also you will be
revealed with Him in glory.
    -- Colossians 3:4 (Green’s Literal Translation)

I disagree. Himalaya is great exactly because it strikes a balance 
between being high-level and easy to reason about, while still being 
useful in a shell script. This sort of composability is what makes it 
great and should be encouraged.

Assuming the user knows what shell piping is (which is a reasonable 
expectation for a CLI,) Clément's example makes total sense IMO.

> Do you expect himalaya to be used by a human user for their mail needs
> (something like MH Mail NG), or is it meant to be just shell API for
> real applications to use (like what your vim and Emacs plugins do)?

For me it is both, you have access to a minimalist UI for interacting
directly with your emails (as a human) AND you have access to a JSON API
(for scripts and interfaces).

I agree with Magnus on this point :)