~soywod/pimalaya#196: 
Make Maildir backend more customizable

Thank you very much for neverest. It’s terrific! I would like to switch and leave mbsync behind.

With mbsync/isync the local maildir structure looks like:

.
├── Archive
│  ├── cur
│  ├── new
│  └── tmp
├── […]
├── Inbox
│  ├── cur
│  ├── new
│  └── tmp
└── Trash
   ├── cur
   ├── new
   └── tmp

With neverest the folder structure is:

.
├── .Archive
│  ├── cur
│  ├── new
│  └── tmp
├── […]
├── .Trash
│  ├── cur
│  ├── new
│  └── tmp
├── cur
├── new
└── tmp

Now I have two questions:

  • Is this the intended behavior?
  • How is it possible to simulate the old structure with aliases, or (if this is not possible) how is it possible to use an Inbox folder for the use e.g. with aerc?

Thank you very much!

Status
REPORTED
Submitter
~neff
Assigned to
No-one
Submitted
3 months ago
Updated
3 months ago
Labels
No labels applied.

~soywod 3 months ago

With mbsync/isync the local maildir structure looks like […].

With neverest the folder structure is […].

Is this the intended behavior?

Yes, it follows the Maildir++ convention. Maildir is not recursive by default. Maildir++ can contain other Maildir++ folders, the only requirement is that they should start by a dot.

https://www.courier-mta.org/imap/README.maildirquota.html

How is it possible to simulate the old structure with aliases

Before doing anything, please backup your emails as Neverest is still in beta. And use as much --dry-run as possible.

I played a bit with the mbsync folder structure but I cannot make it properly work with Neverest. We definitely need to be more compatible. I come back to you whenever I have a solution.

how is it possible to use an Inbox folder for the use e.g. with aerc?

It is not possible at the moment, but I am pretty sure we can find a nice solution.

Nothing to deal with, but you may find [Himalaya] a nice alternative to aerc as well:

https://github.com/soywod/himalaya

~soywod 3 months ago

How mbsync treats nested folders? Does it flatten them? Or it respects the structure?

~neff 3 months ago

Thank you very much for your quick reply and your helpful answers.

Yes, it follows the Maildir++ convention. Maildir is not recursive by default. Maildir++ can contain other Maildir++ folders, the only requirement is that they should start by a dot.

OK! I hadn’t looked into it enough yet. The maildir configuration page does not mention Maildir++. Maybe this could be added.

Before doing anything, please backup your emails as Neverest is still in beta. And use as much --dry-run as possible.

Thanks for your concern. I have a backup system.

I played a bit with the mbsync folder structure but I cannot make it properly work with Neverest. We definitely need to be more compatible. I come back to you whenever I have a solution.

Excellent!

Nothing to deal with, but you may find [Himalaya] a nice alternative to aerc as well:

I played with Himalaya months ago and was very impressed. I don’t know whether a CLI program can replace my current TUI workflow. But I’ll look into it again.

How mbsync treats nested folders? Does it flatten them? Or it respects the structure?

It seems to respect the folder structure. I also used to use an email account with all folders within an INBOX folder.

Thanks a lot again!

~soywod 3 months ago

The maildir configuration page does not mention Maildir++.

You right, it should definitely be mentioned! Thank you for pointing it out.

Nothing to deal with, but you may find Himalaya a nice alternative to aerc as well

I played with Himalaya months ago and was very impressed. I don’t know whether a CLI program can replace my current TUI workflow. But I’ll look into it again.

The CLI improved a bit its user experience since, but it remains a CLI. My next task is to develop a REPL, this may interest you more. It should be a half way between a raw CLI and a TUI. You can see it as an interactive CLI with completion, in a main loop. But it will not be a full TUI alla aerc, with keybinds etc.

Stay tuned!

How mbsync treats nested folders? Does it flatten them? Or it respects the structure?

It seems to respect the folder structure.

Good to know, thank you.

I also used to use an email account with all folders within an INBOX folder.

Looks similar to how Maildir++ works.

To summarize, sync folders are not (yet) compatible between Neverest and mbsync, so you cannot reuse it ATM. The best is just to restart a sync from scratch. Regarding aerc, you should be able to make the inbox point to the root folder of the sync dir (in Maildir++, the root folder is the INBOX and other subfolders start by a dot).

https://pimalaya.org/himalaya/cli/latest/usage/advanced/account/sync.html

~neff 3 months ago

You right, it should definitely be mentioned! Thank you for pointing it out.

Excellent. Your reference to maildir++ solved my problem completely. I just didn’t recognize it because I was not familiar with maildir++’s folder structure. So, maybe this issue can be closed?!

@himalaya

Tested it again, and it’s terrific. Together with helix as $EDITOR and bat or less as a pager it almost has REPL vibes because it’s so intuitive to use. Looking forward to a real REPL version.

Thanks a lot. I’m very happt because I could drop mbsync in favor of neverest!

~soywod 3 months ago

Excellent. Your reference to maildir++ solved my problem completely. I just didn’t recognize it because I was not familiar with maildir++’s folder structure. So, maybe this issue can be closed?!

I would rename and keep this issue for better customization of the Maildir structure (Maildir or Maildir++ variant? Flatten folders? Which folder name encoder?).

Tested himalaya again, and it’s terrific. Together with helix as $EDITOR and bat or less as a pager it almost has REPL vibes because it’s so intuitive to use. Looking forward to a real REPL version.

I am really happy to hear that! I will let you know whenever the REPL work starts.

Thanks a lot. I’m very happt because I could drop mbsync in favor of neverest!

Just a side note: both Neverest and Himalaya handle sync, but not in the same way. Neverest sync is generic, Himalaya sync is not: it uses a hidden Maildir behind the scene so you can consult your email while offline. So technically you can configure Neverest the same way as Himalaya. Both use email-lib so they reuse the same cache, yet I would not advise to use both at the same time. If you only want to sync emails, use Neverest, but if you want to manage them as well, switch to Himalaya. See the FAQ for more details:

https://pimalaya.org/neverest/cli/latest/faq.html#how-different-is-neverest-cli-from-himalaya-cli

~neff 3 months ago

I would rename and keep this issue […]

Yes, that’s better ;-)

[…] I will let you know whenever the REPL work starts.

Excellent. Thanks a lot. I’ll follow your gigantic project anyways.

[…] both Neverest and Himalaya handle sync, but not in the same way. Neverest sync is generic, Himalaya sync is not […]

Yep, I got this. Actually, I like a modular setup with neverest for synchronization.

Maybe, himalaya will support something like

sync.cmd = "neverest synchronize %a"

in the future with %a being the account name – similar to envelope.watch.any.cmd? (Sorry, if this is a naive suggestion or too off-topic. I didn’t follow development closely enough.)

THX!

~soywod 3 months ago

Maybe, himalaya will support something like:

sync.cmd = "neverest synchronize %a"

Despite the fact that I like the idea, it does not make sense simply because both Neverest and Himalaya use the same lib, the same code to sync. Also, someone could decide to use sth else that Neverest, not sure how it would result in. The actual way to link them is just to make them point to the same Maildir. From Himalaya:

sync.enable = true sync.dir = "/my/maildir"

From Neverest:

left.backend.type = "maildir" left.backend.root-dir = "/my/maildir"

Both himalaya account sync and neverest sync should work in harmony. Should.

-- Regards Clément DOUIN https://soywod.me

~neff 3 months ago

Perfect 👍

Register here or Log in to comment, or comment via email.