It is showing newer mail but only from INBOX/cur, not INBOX/new.

~kmaasrud do you have the same behaviour with your new maildirpp crate?

I know, shellexpand-utils uses it :D

shellexpand-utils exposes useful functions based on shellexpand, to avoid rewriting the same code everywhere.

Why not use shellexpand directly?

This type of shell expansion should not be the responsibility of any library

Not sure to follow, you mean that it should not be inside email-lib?

Loading a Maildir with email-lib is done by supplying e.g. a PathBuf. A library should not be making any assumptions about where that path comes from, but accept it as is. By doing shell expansions, we are assuming that email-lib is being used by a user on the shell, but that is really only the case for interactive usage of the Himalaya CLI. A contrived example could be if I were to write a web-app using email-lib which accepted web-hosted Maildirs. Tildes are supported in URLs, but should not be expanded in this case.

Another point is the principle of limiting the scope of a library. An email library should generally only email-specific problems, and assume as little as possible about the context.

A shellexpand crate already exists actually: https://docs.rs/shellexpand/latest/shellexpand/

This type of shell expansion should not be the responsibility of any library, but it could make sense to include in the Himalaya CLI. We need to be careful if we are applying it to the configuration file, though, as expansion is not part of the TOML language so we might hit some snags.

It was a good occasion to do sth I wanted since a while: extract shell expand actions (including canonicalization of paths) into a dedicated crate shellexpand-utils and use it accross libs. This way we have common shell expanding behaviours.

~polyzen the fix is on master, could you try from sources at least to check if it fixes your issue? If so I will release a minor version.

~kmaasrud this shellexpand-utils could be useful for you new maildirpp crate, to expand and validate paths!

Are we expanding tildes into user home dirs? That does not happen natively when deserializing a Path, as the shell is usually responsible for the expension, so I think that is the culprit.

Write the Maildir path in its fully expanded form (/home/user/.mail/...), then everything should be fine.

On 8/28/23 17:18, ~kmaasrud wrote:

This is expected functionality, isn't it? What am I missing?

It's creating these under whatever directory you're currently in, while still reading the actual contents of $HOME/.mail/arch. You end up with these new directories/files under, eg., $HOME/~/.mail/arch. In the example in the original message, these files were under /tmp/~/.mail/arch.

-- Best, Daniel https://danielcapella.com

This is expected functionality, isn't it? What am I missing?

Because let's say you have an email remotely (IMAP) but not locally (Maildir). How to distinguish:

• The email existed remotely and got deleted locally
• The email did not exist locally and got added remotely

I might be øversimplifying so feel free to correct me, but don't we just look at the edit time of the file and compare with the edit time in the remote? I would also say any destructive action must get synced immediately with the remote though, to avoid dangerous diffs. Or we could store user operations with corresponding timestamps in a JSON file in the data dir. We're not talking about a lot of data to resolve any diffs, so that should be fine, shouldn't it?

My intuition tells me no, because we need meta of deleted items. How to get them if items are not there anymore?

Why not just utilize the D (deleted) flag? The distinction of bearing the D flag and being removed from the file system is basically the same as IMAPs distinction between being in the Trash folder and being purged.

We already use a database (SQLite) for storing cache and meta data related to synchronization (mostly ids and envelopes)

Given that a Maildir also works as a full backend for Himalaya, what hinders us in using it for the whole sync and ditch the database? We could for example use the messages' filename to store metadata?