~kmaasrud

Oslo

https://kmaasrud.com

Trackers

~kmaasrud/nvlp

Last active 4 months ago

~kmaasrud/maildirpp

Last active 9 months ago

#41 Add notice when configuring Gmail account in wizard 3 months ago

~soywod unassigned ~kmaasrud from #41 on ~soywod/pimalaya

#132 `himalaya` creates directories/files under ./~ 8 months ago

on ~soywod/pimalaya

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?

#132 `himalaya` creates directories/files under ./~ 8 months ago

Comment by ~kmaasrud on ~soywod/pimalaya

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.

#132 `himalaya` creates directories/files under ./~ 8 months ago

Comment by ~kmaasrud on ~soywod/pimalaya

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.

#132 `himalaya` creates directories/files under ./~ 8 months ago

on ~soywod/pimalaya

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!

#132 `himalaya` creates directories/files under ./~ 8 months ago

Comment by ~kmaasrud on ~soywod/pimalaya

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.

#132 `himalaya` creates directories/files under ./~ 8 months ago

on ~soywod/pimalaya

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

#132 `himalaya` creates directories/files under ./~ 8 months ago

Comment by ~kmaasrud on ~soywod/pimalaya

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

#128 Improve sync 9 months ago

Comment by ~kmaasrud on ~soywod/pimalaya

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?

#128 Improve sync 9 months ago

Comment by ~kmaasrud on ~soywod/pimalaya

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.